versionamento di java

[Nicola Pedot]

Ciao,
per curiosità riporto alcuni passaggi (facendo il possibile per non distorcere il senso) di una discussione sui numeri di versione Java, in effetti anch'io penso l'attuale soluzione sia una pezza ad uno schema bruttino:

----

Oracle announced a change of the Java versioning:
http://www.oracle.com/technetwork/java/javase/overview/jdk-version-number-scheme-1918258.html

Short:
Java releases, however we are changing the frequency and way in which
these releases are numbered:

- Limited Update releases will be numbered in multiples of 20.
- We intend for Critical Patch Updates to continue to use odd numbers.
The numbers will be calculated by adding multiples of five to the prior
Limited Update and when needed adding one to keep the resulting number odd.

Does that sound like old Basic days where we incremented line numbers by
100 to have room for insertions?
What comes next, security versions always use a prime number increase?

...

Since Java 7 launched only the qualifier was changed, no minor (7) or
micro (0) changes.
But in fact we have seen changes that deserve even a minor version bump
when looking from the hotspot perspective. And yes, the hotspot version
has changed accordingly, even a major increase!

I gathered so far:
7u2 Hotspot 22
7u3 Hotspot 22.1
7u4 Hotspot 23
7u5 Hotspot 23.1
7u6 Hotspot 23.2
7u7 Hotspot 23.3
7u9 Hotspot 23.5
7u10 Hotspot 23.6
7u13 Hotspot 23.7
7u21 Hotspot 23.21

I would not like to have even more crazy version numbers, but return to
something that is more transparent.
....

-----------------

Risposta Oracle...

...

To understand why a completely new "X.Y.Z.z'" format wasn't used as "seems the obvious solution" to many, and why this funny looking "XuY [y +20 / +5 even/odd]" approach was taken, you only need to look back at what happened during an Oracle Java 6 update 21 a few years ago.  During a early access update, the vendor string for Oracle Java changed from Sun to Oracle.  This seemingly insignificant change caused a lot of chaos with tools providers [2] and Sys Admin scripts that had built in dependencies -- to the vendor string of all things.  I remember it well because I worked at the Eclipse Foundation at the time, and simply changing the damn vendor string threatened to break Eclipse.  Thankfully Oracle recognized the impact to the ecosystem from the EA and reverted it quickly.  It was also at that time several popular tool dependencies were added to the validation process to try to better recognize the impact of such seemingly simple changes in advance....

...

     changing the form of the version number is really only appropriate to do in a major
version change.  It also needs to be done with sufficient notice and in time for everyone to prepare and test.
As such, we do not intend to do it in an update of 7, and are unlikely to do it in 8 -- otherwise you would have
been likely to see a JEP for this by now (as 8 is only a couple of weeks from feature complete).

    As we have seen in the past, the fact that there is sometimes a need to introduce new versions on short
notice means that there is some amount of unpredictability in the version numbers anyway -- the scheme
that is outlined on the linked page is intended to increase predictability and also provide transparency of
how the version numbers are determined (and what they mean).

NiPe

[Chris Mair]

Ciao.

> > http://www.oracle.com/technetwork/java/javase/overview/jdk-version-number-scheme-1918258.html

> The next Limited Update for JDK 7 will be numbered 7u40, and the next 3 CPUs after that will be numbered 7u45, 7u51, and 7u55. The next release will be a Limited Update 7u60, followed by CPUs
> 7u65, 7u71, and 7u75.
>
> This numbering scheme will leave several numbers between releases which will allow us to insert releases � for example security alerts or support releases, should that become necessary -
> without having to renumber later releases.


Ciao,

ho dovuto controllare la data della press release (che non sia il primo Aprile)...
L'unica altra spiegazione e` che l'autore del basic del C64 ora lavoro per Oracle ;)

Bye,
Chris.