"Pour éviter la confusion causée par les renumérotations de versions", Oracle a annoncé qu'il se dote d'une nouvelle numérotation pour JDK 5.0, JDK 6 et JDK 7. Les versions mineures de Java sont divisées entre les versions planifiées "Limited Update" qui incluent des correctifs de bogues non liés à la sécurité et de nouvelles fonctionnalités occasionnelles, et les versions "Critical Patch Updates" (CPU) qui comprennent uniquement des correctifs pour les vulnérabilités de sécurité. L'augmentation de la fréquence des versions correctives pour la sécurité signifie que les versions prévues doivent parfois être renumérotées. Ce qui provoque des problèmes pour Oracle puisque cela signifie que les corrections et améliorations ne peuvent pas être attribuées à certaines versions spécifiques dans les systèmes de suivi des bogues.
Pour contourner ceci, Oracle a décidé que :
- Les versions "Limited Update" seront numérotées en multiples de 20.
- Nous avons l'intention pour les mises à jour de correctifs critiques de continuer à utiliser des numéros impairs. Les chiffres seront calculés en ajoutant des multiples de cinq à la version "Limited Update" précédente et si nécessaire ajouter un pour maintenir le numéro de version impair.
C'est mieux illustré par un exemple :
La prochaine "Limited Update" pour JDK 7 sera numérotée 7u40, et les 3 prochains CPUs après seront numérotés 7u45, 7u51 et 7u55. La prochaine version sera une "Limited Update" 7u60, suivie des CPUs 7u65, 7u71, et 7u75.Ce format laissera plusieurs numéros entre les versions qui vont nous permettre d'insérer des versions - par exemple des versions lors d'alertes de sécurité ou des versions pour le support, si cela s'avérait nécessaire - sans avoir à renuméroter les versions ultérieures.
Tout en notant qu'il n'était pas impliqué dans les discussions autour de cela, Phil Race d'Oracle, qui a été ingénieur de l'équipe du client Java de Sun/Oracle plus de 12 ans, fournit quelques détails sur la liste de diffusion OpenJDK
Cela devient une convention que les mises à jour de sécurité soient des nombres impairs et que les autres versions soient des nombres pairs. Je ne sais pas à quel point cela est important pour le monde extérieur, mais si deux versions de sécurité se produisent sans une sortie entre, vous devez décider si vous voulez briser cette convention.
Nous avons également eu beaucoup de confusion découlant de la nécessité de faire quelques versions imprévues. Les builds de la version 7u14 existaient, des bogues ont été marqués comme corrigés dans cette version, des rapports, des statistiques, etc.. tout se referrait à cette version, mais toutes ces données sont maintenant fausses, et ce travail va maintenant (espérons-le) voir la lumière du jour lors de la version 7u40. Pendant ce temps, intérieurement et extérieurement les gens ne pouvaient pas comprendre pourquoi un bug corrigé dans la soi-disant 7u14 était reproductible en 7u17. Donc, en laissant un espace très généreux entre les numéros de version non-sécurité signifie que nous ne devrions pas avoir à faire la renumérotation à la volée.
Laisser des espaces entre les numéros de versions de sécurité prévues veut dire qu'il y a déjà un lieu réservé au cas où un imprévu doit arriver. Garder la convention de numérotation impaire pour les versions de sécurité utilise plus de numéros. C'est comme ça que vous vous retrouvez avec de tels sauts incompréhensibles dans les nombres.
par exemple:
7u15 était une version de sécurité prévue
7u17 n'était pas prévue, en utilisant un numéro réservé (je crois)
7u19 était réservée au cas où, mais pas nécessaire
7u21 était une version de sécurité prévue
et ainsi de suite ...
Oracle note qu'une solution plus élégante nécessiterait la modification du schéma de numérotation pour s'adapter à différents types de changements (par exemple en utilisant 7u44-2). Mais cela ne peut pas être mis en œuvre en dehors d'une version majeure, car cela pourrait casser le code existant qui analyse les numéros de version (y compris éventuellement le système d'auto-mise à jour Java), d'une manière qui rappelle vaguement de ce qui s'est passé quand le nom a changé de la société Sun Microsystems à Oracle. En outre, il est peu probable de faire ce changement à temps pour la version 8 de Java qui est déjà très en retard.