Atualizações frequentes do sistema operacional são essenciais para garantir a segurança e o acesso aos recursos mais recentes. Por padrão, o ChromeOS lança uma atualização completa do SO para o canal estável (Stable) a cada quatro semanas. As atualizações menores, como correções de segurança e atualizações de software, ocorrem a cada duas ou três semanas. Os desenvolvedores podem testar os aplicativos nos canais de desenvolvedor (Dev) ou Beta antes do lançamento de cada nova versão estável para garantir que os apps funcionem bem. Ele é atualizado uma ou duas vezes por semana e mostra em que a equipe do Chrome está trabalhando no momento. Essa versão ainda está sujeita a bugs, mas oferece uma prévia de 9 a 12 semanas do que está chegando à versão estável. O Beta oferece uma prévia de quatro a seis semanas dos recursos que serão lançados na versão Stable.
No entanto, testar mensalmente com esses canais pode ser difícil para administradores de sistema e desenvolvedores. Para oferecer um suporte melhor e dar mais tempo para todos testarem, criamos um novo plano de suporte de longo prazo, com canais de suporte de longo prazo, para o ChromeOS.
Versões com suporte de longo prazo
As versões de suporte de longo prazo do ChromeOS são uma ferramenta eficiente para reduzir o esforço de gerenciar dispositivos em uma organização e certificar que os apps funcionam bem em todas as atualizações do SO. Administradores e desenvolvedores precisam conhecer esses recursos para oferecer uma ótima experiência às organizações que os adotam.
O ChromeOS oferece duas versões de suporte de longo prazo: uma versão candidata ao suporte de longo prazo (LTC) e uma versão estável de longo prazo (LTS).
- Candidato ao suporte de longo prazo (LTC): usado como base para a próxima versão do LTS e é cortado do Stable três meses antes do LTS, aos administradores uma prévia para se preparar.
- Canal de suporte de longo prazo (LTS): atualizado a cada seis meses, esse canal tem o ritmo de lançamento mais lento e foi criado como substituto do canal estável normal. Exceto por alguns usuários que devem permanecer no LTC para fins de teste, a maioria precisa estar no LTS ao adotar versões de suporte de longo prazo em uma organização.
Cronograma de lançamentos estáveis, LTC e LTS
O ciclo de vida do LTC / LTS funciona da seguinte maneira:
- A versão LTC (108 LTC no diagrama) é cortada da versão estável (108 Stable). Portanto, durante o primeiro mês, ambas são idênticas.
- O LTC começa a receber correções de segurança a cada duas semanas pelos próximos três meses até o próximo lançamento do LTS (LTS 108 no diagrama). Isso significa que, três meses após o lançamento inicial do LTC, ele vai espelhar o LTS.
- Depois que o LTS for lançado, ele vai continuar recebendo correções de segurança a cada duas semanas.
- Os dispositivos mantidos no LTC após o lançamento do LTS também vão continuar recebendo correções de segurança a cada duas semanas e serão atualizados automaticamente para a próxima versão do LTC quando ela for lançada.
Além de recursos do sistema operacional e correções de bugs, as atualizações de firmware também são agrupadas em versões LTS até a expiração da atualização automática (AUE) de um dispositivo.
Para ativar qualquer um dos canais, você precisa ter um domínio do Google e um dispositivo gerenciado. Você pode se inscrever em uma avaliação do Upgrade do Chrome Enterprise para ter acesso ao Google Admin Console e configurar e implantar Chromebooks gerenciados. Por fim, mude os dispositivos gerenciados para o canal LTS ou LTC no Admin Console. Recomendamos manter a maioria dos dispositivos no canal LTS e usar o LTC para testar a próxima versão do LTS.
Fluxo de trabalho de teste para LTC / LTS
O LTC e o LTS foram criados para reduzir consideravelmente os esforços de teste dos administradores, garantindo uma experiência segura com o sistema operacional. Para manter os administradores de sistema e desenvolvedores alinhados com o ciclo de vida de suporte de longo prazo, faça o seguinte:
- Teste no Dev e no Beta antes do lançamento da versão estável que corresponde ao próximo lançamento do canal LTC.
- Quando o LTC for lançado, teste-o para garantir que as correções de segurança aplicadas não afetem seu trabalho até que o LTS seja desativado.
- Depois que o LTC for promovido para LTS, o LTS vai continuar recebendo correções de segurança a cada duas semanas. Você também precisa testá-las.
Usando o diagrama do ciclo de vida como referência:
- Comece a testar nas versões 108 Dev e 108 Beta para garantir que tudo funcione bem antes do lançamento da versão 108 Stable, que será a base da 108 LTC.
- Teste em 108 LTC a cada duas semanas até que 108 LTS seja lançado três meses após a data de corte inicial.
- Continue testando regularmente na LTS para garantir que as correções de segurança não quebrem nada.
Gerenciar mudanças entre versões do LTC/LTS
Se você adotar uma versão de suporte de longo prazo do ChromeOS ou trabalhar com uma organização que já fez isso, é fundamental gerenciar corretamente as mudanças entre as versões. Você pode adicionar um recurso com base em novas funcionalidades da plataforma ou usar um que foi descontinuado em versões posteriores. Ou você pode depender de recursos específicos de uma versão específica de um app ou querer oferecer aos usuários a capacidade de escolher qual versão executar. Para garantir o acesso contínuo ao aplicativo, trabalhe para que ele seja compatível com versões anteriores, forneça instâncias separadas por versão ou ambos.
Garantir a compatibilidade com versões anteriores
A compatibilidade com versões anteriores permite que versões mais recentes do aplicativo sejam executadas em versões mais antigas da plataforma. Isso pode ser feito com uma técnica chamada detecção de recursos, em que você verifica a disponibilidade de um novo recurso antes de tentar usá-lo. Se ele existir, use-o. Caso contrário, forneça um substituto opcional. A versão generalizada dessa técnica é chamada de flags de recursos, em que um codepath é carregado dependendo se um recurso está ativado, seja pela disponibilidade de recursos ou pela configuração no nível do app ou do usuário. Apps Android, extensões do Chrome e apps da Web se beneficiam dessa técnica. Ao garantir que as versões mais recentes do app sejam compatíveis com versões anteriores, você pode gerenciar um único aplicativo para todos os usuários.
Um web app que quer oferecer animações com uso intenso de computação pode implementar a WebGPU para navegadores compatíveis e usar animações mais simples com tecnologia JavaScript se ela não estiver disponível. Para isso, eles podem fazer o seguinte:
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
Fornecer instâncias separadas
Às vezes, as diferenças entre as versões são muito grandes para serem processadas com técnicas de compatibilidade com versões anteriores. As diferenças de recursos podem ser muito grandes, ou você pode ter necessidades comerciais que exigem uma versão de suporte de longo prazo separada do seu aplicativo principal. Nesse caso, considere fornecer instâncias separadas para cada versão. Isso garante que os usuários estejam usando uma versão específica do app, mas pode aumentar os custos operacionais. Portanto, pense nisso ao optar por essa solução.
Para apps da Web, fornecer uma instância separada geralmente significa hospedar as diferentes versões do aplicativo em URLs diferentes, o que pode exigir servidores, bancos de dados ou outra infraestrutura de site separados. Para aplicativos Android, isso significa ter páginas "Detalhes do app" separadas na Play Store para cada versão. Isso pode confundir os usuários, já que haveria vários aplicativos semelhantes disponíveis, e eles não saberiam qual escolher. As extensões do Chrome também podem ter várias listagens, ou você pode recomendar que os clientes fixem a versão da extensão do Chrome de que precisam no Admin Console do Chrome. Para isso, consulte esta documentação, que detalha como fixar extensões e algumas restrições associadas a essa ação.
Um app Android que queira oferecer apenas uma versão de suporte de longo prazo para usuários do ChromeOS pode criar uma página separada com o seguinte no arquivo AndroidManifest.xml para especificar que ele só deve ser entregue a dispositivos ChromeOS:
<uses-feature android:name="org.chromium.arc" android:required="true" />