JEP 223: New Version-String Scheme

[Mario Torre]

On Thu, 2014-11-06 at 02:41 +0100, Remi Forax wrote:
> On 11/06/2014 12:59 AM, Iris Clark wrote:
> > Hi, Remi.
> >
> > Thanks for taking time to read the JEP.
> >
> >>> New JEP Candidate: http://openjdk.java.net/jeps/223
> >> 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.
> > Do you have any backing data for this?  The biggest potential problem we
> > anticipate at this time is existing code which assumes that the initial
> > element is a '1' and just skips it when comparing version numbers.  At this
> > point, we suspect that this code is rare, but perhaps that's not correct?  Do
> > you know of any other significant risks that we did not list?
> 
> no, I've no more data than you.
> 
> but you ask the question the wrong way, you want to change something 
> that I think doesn't need to change,
> so the question is more what is the benefit of removing the first '1' 
> than "we think that there will be no major oops"
> so we can remove the first '1'.
> 
> >
> >> And for the API, version() should be versions() and return an int[]
> >> and build() should return an OptionalInt.
> > What is the benefit of using List/array and primitive/reference types in this
> > case?  Conversion between them is straight-forward.
> 
> What is the benefit to use a List instead of an int[] ?
> The version will be loaded early in the process, if we can avoid a 
> dependency on java.util.List,
> I think it's a net gain.

Arrays are so old fashioned!

Mario