लंबे समय तक सहायता देने वाले वर्शन

ऑपरेटिंग सिस्टम को समय-समय पर अपडेट करना ज़रूरी है. इससे सुरक्षा बनी रहती है और नई सुविधाओं का ऐक्सेस मिलता है. डिफ़ॉल्ट रूप से ChromeOS, स्टेबल चैनल (स्टेबल) के लिए ऑपरेटिंग सिस्टम का पूरा अपडेट करीब हर चार हफ़्तों में रिलीज़ करता है. सुरक्षा से जुड़े सुधार और सॉफ़्टवेयर अपडेट जैसे छोटे अपडेट, हर दो-तीन हफ़्ते में होते हैं. डेवलपर, हर नए स्टेबल वर्शन के रिलीज़ होने से पहले, अपने ऐप्लिकेशन को डेवलपर (डेव) या बीटा (बीटा) चैनल पर टेस्ट कर सकते हैं. इससे यह पक्का किया जा सकता है कि उनके ऐप्लिकेशन ठीक से काम कर रहे हैं. डेव चैनल को हफ़्ते में एक या दो बार अपडेट किया जाता है. इससे पता चलता है कि Chrome की टीम फ़िलहाल किस पर काम कर रही है. इस बिल्ड में अब भी कुछ गड़बड़ियां हो सकती हैं. हालांकि, इससे आपको यह पता चल जाता है कि स्टेबल वर्शन में क्या-क्या सुविधाएं आने वाली हैं. इसकी झलक 9 से 12 हफ़्तों तक दिखती है. बीटा चैनल में, स्टेबल चैनल में आने वाली सुविधाओं की झलक 4 से 6 हफ़्तों तक देखी जा सकती है.

हालांकि, सिस्टम एडमिन और डेवलपर के लिए, हर महीने इन मौजूदा चैनलों पर टेस्टिंग करना मुश्किल हो सकता है. हम ChromeOS के लिए, लंबे समय तक सहायता देने वाला एक नया प्लान लेकर आए हैं. इसमें लंबे समय तक सहायता देने वाले चैनल भी शामिल हैं. इससे हम बेहतर सहायता दे पाएंगे और सभी को टेस्ट करने के लिए ज़्यादा समय मिल पाएगा.

लंबे समय तक सहायता देने वाले वर्शन

ChromeOS के लॉन्ग-टर्म सपोर्ट रिलीज़, किसी संगठन में डिवाइसों को मैनेज करने में लगने वाले समय को कम करने का एक बेहतरीन टूल है. साथ ही, यह सर्टिफ़िकेट देता है कि हर ओएस अपडेट के लिए ऐप्लिकेशन सही तरीके से काम करते हैं. एडमिन और डेवलपर, दोनों को इन सुविधाओं के बारे में पता होना चाहिए, ताकि इन्हें अपनाने वाले संगठनों को बेहतर अनुभव दिया जा सके.

ChromeOS के लिए, लंबे समय तक सहायता देने वाले दो वर्शन उपलब्ध हैं: लंबे समय तक सहायता देने वाला कैंडिडेट (एलटीसी) वर्शन और लंबे समय तक स्टेबल (एलटीएस) वर्शन.

  • लंबे समय तक सहायता देने वाला कैंडिडेट (एलटीसी) - इसका इस्तेमाल, एलटीएस के अगले वर्शन के आधार के तौर पर किया जाता है. इसे एलटीएस से तीन महीने पहले स्टेबल वर्शन से हटा दिया जाता है, ताकि एडमिन को तैयारी करने के लिए इसकी झलक मिल सके.
  • लंबे समय तक सहायता देने वाला चैनल (एलटीएस) - इस चैनल को हर छह महीने में अपडेट किया जाता है. इसमें सबसे कम अपडेट रिलीज़ किए जाते हैं. इसे सामान्य स्टेबल चैनल के विकल्प के तौर पर इस्तेमाल किया जाता है. कुछ उपयोगकर्ताओं को छोड़कर, ज़्यादातर उपयोगकर्ताओं को एलटीएस पर होना चाहिए. इन उपयोगकर्ताओं को टेस्टिंग के लिए एलटीसी पर रखा जाता है.

स्टेबल, एलटीसी, और एलटीएस रिलीज़ की समयसीमा

स्टेबल, एलटीसी, और एलटीएस रिलीज़ की समयसीमा

एलटीसी / एलटीएस का लाइफ़साइकल इस तरह काम करता है:

  • एलटीसी रिलीज़ (डायग्राम में 108 एलटीसी) को स्टेबल रिलीज़ (108 स्टेबल) से अलग किया जाता है. इसलिए, पहले महीने के दौरान दोनों एक जैसे होते हैं.
  • एलटीसी को अगले तीन महीनों तक, हर दो हफ़्ते में सुरक्षा से जुड़े सुधार मिलते हैं. ऐसा तब तक होता है, जब तक अगला एलटीएस वर्शन (डायग्राम में 108 एलटीएस) रिलीज़ नहीं हो जाता. इसका मतलब है कि एलटीसी की शुरुआती रिलीज़ के तीन महीने बाद, एलटीसी, एलटीएस की तरह काम करेगा.
  • एलटीएस रिलीज़ होने के बाद, इसे हर दो हफ़्ते में सुरक्षा से जुड़े सुधार मिलते रहेंगे.
  • एलटीएस रिलीज़ होने के बाद भी जिन डिवाइसों को एलटीसी पर रखा जाता है उन्हें हर दो हफ़्ते में सुरक्षा से जुड़े सुधार मिलते रहेंगे. साथ ही, एलटीसी बंद होने पर डिवाइस, एलटीसी के अगले वर्शन पर अपने-आप अपडेट हो जाएंगे.

ऑपरेटिंग सिस्टम की सुविधाओं और गड़बड़ियों को ठीक करने के अलावा, फ़र्मवेयर अपडेट भी एलटीएस रिलीज़ में बंडल किए जाते हैं. ये अपडेट, डिवाइस के अपने-आप अपडेट होने की आखिरी तारीख (एयूई) तक मिलते हैं.

इनमें से किसी भी चैनल को चालू करने के लिए, आपके पास Google डोमेन और मैनेज किया गया डिवाइस होना चाहिए. Google Admin console का ऐक्सेस पाने के लिए, Chrome Enterprise Upgrade के ट्रायल के लिए साइन अप करें. इससे आपको मैनेज किए जा रहे Chromebooks को सेट अप और डिप्लॉय करने की सुविधा मिलेगी. आखिर में, Admin console में जाकर मैनेज किए जा रहे डिवाइसों को एलटीएस या एलटीसी चैनल पर स्विच करें. हमारा सुझाव है कि ज़्यादातर डिवाइसों पर एलटीएस चैनल का इस्तेमाल करें. साथ ही, एलटीसी का इस्तेमाल करके, एलटीएस की आने वाली रिलीज़ को टेस्ट करें.

एलटीसी / एलटीएस के लिए टेस्टिंग वर्कफ़्लो

एलटीसी और एलटीएस को इस तरह से डिज़ाइन किया गया है कि एडमिन को टेस्टिंग में कम समय लगे. साथ ही, ऑपरेटिंग सिस्टम को सुरक्षित तरीके से इस्तेमाल किया जा सके. सिस्टम एडमिन और डेवलपर को लंबे समय तक सहायता देने से जुड़े लाइफ़साइकल के बारे में जानकारी देने के लिए, आपको यह काम करना चाहिए:

  • एलटीसी चैनल पर रिलीज़ होने वाले वर्शन से मेल खाने वाले स्टेबल वर्शन को रिलीज़ करने से पहले, उसे Dev और Beta पर टेस्ट करें.
  • एलटीसी रिलीज़ होने के बाद, उस पर टेस्ट करें. इससे यह पक्का किया जा सकेगा कि सुरक्षा से जुड़े लागू किए गए किसी भी फ़िक्स से, एलटीएस के बंद होने तक आपके काम पर कोई असर न पड़े.
  • एलटीसी को एलटीएस में प्रमोट किए जाने के बाद, एलटीएस को हर दो हफ़्ते में सुरक्षा से जुड़े सुधार मिलते रहेंगे. आपको इनकी भी जांच करनी चाहिए.

लाइफ़साइकल डायग्राम को रेफ़रंस के तौर पर इस्तेमाल करके:

  • 108 Dev और 108 Beta वर्शन पर टेस्टिंग शुरू करें. इससे यह पक्का किया जा सकेगा कि 108 Stable वर्शन के रिलीज़ होने से पहले, सब कुछ सही तरीके से काम कर रहा है. 108 LTC वर्शन, 108 Stable वर्शन से ही बनाया जाएगा.
  • शुरुआती कट डेट से तीन महीने बाद 108 एलटीएस रिलीज़ होने तक, हर दो हफ़्ते में 108 एलटीसी पर टेस्ट करें.
  • एलटीएस पर नियमित रूप से टेस्टिंग जारी रखें, ताकि यह पक्का किया जा सके कि सुरक्षा से जुड़े फ़िक्स से कोई समस्या नहीं आ रही है.

एलटीसी/एलटीएस वर्शन के बीच के बदलावों को मैनेज करना

ChromeOS के लंबे समय तक सहायता पाने वाले वर्शन को अपनाने या ऐसे संगठन के साथ काम करने के दौरान, वर्शन के बीच बदलावों को सही तरीके से मैनेज करना ज़रूरी है. आपके पास नए प्लैटफ़ॉर्म की क्षमताओं के आधार पर कोई सुविधा जोड़ने का विकल्प होता है. इसके अलावा, आपके पास ऐसी सुविधा का इस्तेमाल करने का विकल्प भी होता है जो बाद के वर्शन में बंद कर दी गई थी. इसके अलावा, हो सकता है कि आपको किसी ऐप्लिकेशन के किसी वर्शन की खास सुविधाओं का इस्तेमाल करना हो या उपयोगकर्ताओं को यह चुनने का विकल्प देना हो कि वे कौनसे वर्शन का इस्तेमाल करें. ऐप्लिकेशन को आसानी से ऐक्सेस किया जा सके, इसके लिए आपको यह पक्का करना होगा कि आपका ऐप्लिकेशन पुराने वर्शन के साथ काम करता हो. इसके अलावा, हर वर्शन के लिए अलग-अलग इंस्टेंस उपलब्ध कराएं या दोनों काम करें.

यह पक्का करना कि पुराने सिस्टम के साथ काम करने की सुविधा उपलब्ध हो

बैकवर्ड कंपैटिबिलिटी की मदद से, आपके ऐप्लिकेशन के नए वर्शन, प्लैटफ़ॉर्म के पुराने वर्शन पर काम कर पाते हैं. इसके लिए, फ़ीचर डिटेक्शन नाम की तकनीक का इस्तेमाल किया जा सकता है. इसमें, किसी नई सुविधा का इस्तेमाल करने से पहले, यह देखा जाता है कि वह सुविधा उपलब्ध है या नहीं. अगर यह मौजूद है, तो इसका इस्तेमाल करें. अगर यह मौजूद नहीं है, तो फ़ॉलबैक के तौर पर कोई वैल्यू दें. हालांकि, ऐसा करना ज़रूरी नहीं है. इस तकनीक के सामान्य वर्शन को फ़ीचर फ़्लैग कहा जाता है. इसमें, किसी फ़ीचर के चालू होने के आधार पर कोडपाथ लोड किया जाता है. फ़ीचर को, सुविधा की उपलब्धता या ऐप्लिकेशन या उपयोगकर्ता-लेवल के कॉन्फ़िगरेशन के ज़रिए चालू किया जाता है. इस तकनीक का फ़ायदा Android ऐप्लिकेशन, Chrome एक्सटेंशन, और वेब ऐप्लिकेशन को मिलता है. यह पक्का करके कि आपके ऐप्लिकेशन के नए वर्शन, पुराने वर्शन के साथ काम करते हैं, अपने सभी उपयोगकर्ताओं के लिए एक ही ऐप्लिकेशन को मैनेज किया जा सकता है.

अगर किसी वेब ऐप्लिकेशन को ज़्यादा कंप्यूटिंग पावर वाले ऐनिमेशन दिखाने हैं, तो वह WebGPU को लागू कर सकता है. ऐसा उन ब्राउज़र के लिए किया जा सकता है जो WebGPU के साथ काम करते हैं. अगर WebGPU उपलब्ध नहीं है, तो वह JavaScript की मदद से बनाए गए सामान्य ऐनिमेशन का इस्तेमाल कर सकता है. इसके लिए, वे ये काम कर सकते हैं:

if ('gpu' in navigator) {
  // WebGPU is supported! Accelerate computation.
} else {
  // No WebGPU, fallback to JavaScript implementation.
}

अलग-अलग इंस्टेंस उपलब्ध कराना

कभी-कभी वर्शन के बीच का अंतर इतना ज़्यादा होता है कि उसे बैकवर्ड कंपैटिबिलिटी की तकनीकों से मैनेज नहीं किया जा सकता. ऐसा हो सकता है कि सुविधाओं में बहुत ज़्यादा अंतर हो या आपके कारोबार की ज़रूरतें ऐसी हों कि आपको अपने मुख्य ऐप्लिकेशन के बजाय, लंबे समय तक सहायता पाने वाले किसी अलग वर्शन की ज़रूरत हो. अगर ऐसा होता है, तो हर वर्शन के लिए अलग-अलग इंस्टेंस दिए जा सकते हैं. इससे यह पक्का होता है कि उपयोगकर्ता आपके ऐप्लिकेशन के किसी खास वर्शन का इस्तेमाल कर रहे हैं. हालांकि, इससे आपकी परिचालन लागत बढ़ सकती है. इसलिए, इस समाधान को चुनते समय इस बात का ध्यान रखें.

वेब ऐप्लिकेशन के लिए, अलग इंस्टेंस उपलब्ध कराने का मतलब आम तौर पर यह होता है कि आपके ऐप्लिकेशन के अलग-अलग वर्शन को अलग-अलग यूआरएल पर होस्ट किया जाए. इसके लिए, अलग-अलग सर्वर, डेटाबेस या वेबसाइट के अन्य इन्फ़्रास्ट्रक्चर की ज़रूरत पड़ सकती है. Android ऐप्लिकेशन के लिए, इसका मतलब है कि हर वर्शन के लिए Play Store पर अलग-अलग लिस्टिंग होनी चाहिए. इससे आपके उपयोगकर्ताओं को भ्रम हो सकता है, क्योंकि एक जैसे कई ऐप्लिकेशन उपलब्ध होंगे और उन्हें यह पता नहीं होगा कि कौनसा ऐप्लिकेशन चुनना है. Chrome एक्सटेंशन की एक से ज़्यादा लिस्टिंग भी हो सकती हैं. इसके अलावा, अपने ग्राहकों को यह सुझाव दिया जा सकता है कि वे Chrome Admin console के ज़रिए, अपने Chrome एक्सटेंशन के उस वर्शन को पिन करें जिसकी उन्हें ज़रूरत है. इसके लिए, उन्हें यह दस्तावेज़ भेजें. इसमें एक्सटेंशन पिन करने का तरीका और पिन करने से जुड़ी कुछ चेतावनियों के बारे में बताया गया है.

अगर कोई Android ऐप्लिकेशन, ChromeOS उपयोगकर्ताओं को सिर्फ़ लंबे समय तक काम करने वाला वर्शन उपलब्ध कराना चाहता है, तो वह एक अलग लिस्टिंग बना सकता है. साथ ही, AndroidManifest.xml फ़ाइल में यह जानकारी दे सकता है कि इसे सिर्फ़ ChromeOS डिवाइसों पर डिलीवर किया जाना चाहिए:

<uses-feature android:name="org.chromium.arc" android:required="true" />