O lançamento do Java 9 também trouxe um novo esquema de versão. Este esquema tem como base a JEP 223 e foi destinado a lançamentos futuros da própria plataforma Java.
Entretanto, quase imediatamente após o lançamento, Mark Reinhold, arquiteto chefe Java, anunciou uma nova proposta para mudar o esquema de versão novamente e adotar um modelo estrito com base no tempo.
Os principais objetivos do esquema de versão do JEP 223 são:
- Tornar as versões facilmente compreensíveis por humanos;
- Alinhar com as práticas atuais da indústria;
- Ser adotável por sistemas de empacotamento existentes e mecanismos de implementação;
- Eliminar a prática atual de codificar dois tipos de informação em um elemento de versão textual;
- Fornecer uma API simples para análise de sequência de versão, validação e comparação.
As notas de lançamento do Java 9 descrevem o novo formato de versão como:
$MAJOR.$MINOR.$SECURITY.$PATCH
- $MAJOR - o número de versão é incrementado para uma versão principal, que contém novas funcionalidades significantes conforme detalhamento nas especificações da plataforma Java SE. As funcionalidades de uma grande versão são planejadas e anunciadas com bastante antecedência;
- $MINOR - a versão é incrementada a cada atualização menor, como correções de bugs, revisões de APIs, ou implementações de funcionalidades que não fazem parte do escopo principal;
- $SECURITY - a versão é incrementada para lançamentos de atualização de segurança, que contém correções críticas para melhorar a segurança;
- $PATCH - a versão é incrementada para um lançamento que contém correções de segurança e correções de alta prioridade para o cliente, que precisam ser testadas em conjunto.
Reinhold propôs mudar este esquema em favor de um modelo de lançamento com base em tempo. O argumento é que a plataforma Java SE e o JDK se envolveu em grandes, irregulares e, algumas vezes, fases não previstas durante os últimos vinte anos.
Cada funcionalidade tem sido direcionada de acordo com funcionalidades significantes e a versão geralmente é agendada de acordo com a necessidade, de forma a acomodar o desenvolvimento destas funcionalidades. Reinhold diz que tal programação de lançamentos está ultrapassada, uma vez que o Java agora compete com várias plataformas modernas que evoluem em ritmo mais rápido:
Reinhold: Usando esse modelo de lançamento de outras plataformas como inspiração e por várias distribuições de sistemas operacionais, proponho que após o Java 9, adotemos um modelo estrito baseado no tempo com um lançamento de uma nova funcionalidade a cada seis meses, lançamentos de atualização a cada três meses, e um lançamento de suporte a longo prazo a cada três anos.
De acordo com este modelo, desenvolvedores que preferirem inovação rápida podem usar a versão mais recente, ou uma versão de atualização, e passar para a próxima versão quando ela for lançada. Empresas que preferem estabilidade, podem usar a versão atual de suporte a longo prazo. É possível se planejar com antecedência para migrar de uma versão de suporte de longo prazo para o próximo.
A sequência de versão proposta seria da forma:
$YEAR.$MONTH
Logo, a versão de março de 2018 seria 18.3, e a versão de setembro de 2018 seria 18.9. Reinhold defendeu o uso de tempos absolutos para o controle de versão em uma lista de email jdk-dev da seguinte maneira:
Reinhold:
- Tempos absolutos refletem datas de versão, então fica claro para todos os envolvidos (tanto desenvolvedores do JDK como usuários da JDK) que essas são versões com base no tempo. Não pode haver uma questão de adiar uma versão para adicionar "apenas mais um recurso";
- Tempos absolutos torna fácil a percepção de quão velha uma versão é, então como usuário é possível entender quanto para trás se está. Tempos relativos requerem que se tenha o conhecimento do que unidades de tempo são, e então quando essas versões baseadas no tempo foram adotadas;
- Tempos absolutos são independentes da cadência de versão. Se em alguns anos mudarmos para uma cadência ainda mais rápida, digamos a cada três meses, então um esquema absoluto não precisaria de mudança, mas um esquema relativo precisaria ser revisado com uma nova unidade de tempo e ponto de partida.
O modelo de versionamento com base em tempos absolutos tem se provado impopular para a comunidade e Reinhold produziu uma proposta revisada em um post na lista de email. O esquema da proposta revisada é semelhante ao proposto originalmente na JEP 223 e representa um compromisso entre os dois pontos de vista.
A forma proposta do novo formato de sequência de versão como está é:
$FEATURE.$INTERIM.$UPDATE.$EMERG
- O contador $FEATURE é incrementado a cada seis meses independente do conteúdo da versão;
- O contador $INTERIM é incrementado para versões sem funcionalidades que contém correções de bugs e melhorias compatíveis mas sem mudanças incompatíveis. Esse contador é zerado para o atual modelo de lançamento de seis meses;
- O contador $UPDATE é incrementado a cada três meses para atualizações de versões compatíveis que tenham problemas de segurança e correções de bugs em novas funcionalidades;
- O contador $EMERG é incrementado somente quando necessário para produzir uma versão emergencial para corrigir um problema crítico.
Esse é, primariamente, um esquema com base no tempo. $FEATURE é incrementado a cada seis meses independente do conteúdo da versão e para cada futura versão, $UPDATE é incrementado a cada três meses.
Neste modelo, a próxima versão com funcionalidades (anteriormente chamado major release) do Java ainda seria o Java 10, e seria produzido em março de 2018, com o Java 11 em setembro de 2018. A proposta permanece ativamente em discussão, sendo esperado uma decisão em anúncio em breve.