JEP 223: New Version-String Scheme

[Paul Benedict]

I second what Remi says about dropping the 1. In fact, I think it has been
a grace it hasn't yet been dropped. It allows you to move to "2" when
Oracle (or another future steward) decides to break major backwards
compatibility. Until that happens, there really is no logical justification
to get rid of the 1. Let's not forget Windows 10 is internally 6.4 -- point
being technical numbers are more important than marketing names.

Also, semantic versioning is not a form of math. The next version after 1.9
is 1.10 -- not 2.0 -- and then 1.11, etc. The JEP has this wrong. You keep
on incrementing the minor version until you're ready to break backwards
compatibility. That's where technical Java version 2.0 comes into being.


Cheers,
Paul

On Wed, Nov 5, 2014 at 1:53 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>
> On 11/04/2014 11:05 PM, mark.reinhold at oracle.com wrote:
>
>> New JEP Candidate: http://openjdk.java.net/jeps/223
>>
>> - Mark
>>
>
> Hi Mark,
> I fail to see why dropping the first 1 is interesting.
> While it's true than $MAJOR will be always '1', and that each release
> slightly violating the principle of semantic versioning, it see that more
> like the difference between a principle and the reality than something that
> has to be fixed.
> IMO, having a difference between the marketing name and the engineering
> version value doesn't worth the trouble of the compatibility issues you
> list.
> Why not stick with a 4 components version ?
>
> And for the API, version() should be versions() and return an int[] and
> build() should return an OptionalInt.
>
> cheers,
> Rémi
>
>