Alternative Version implementation

[Neil Bartlett (Paremus)]

The incompatibility with OSGi is easy enough to illustrate — Maven less so because, as David says, Maven versions are chronically underspecified. In OSGi, version 1 and 1.0 and 1.0.0 are strictly identical, with the former two being nothing more than abbreviations for the latter. Also David’s scheme for implicit separators when transitioning between numeric and alphabet characters does not work with OSGi’s qualifier segment, which is a single alphanumeric (plus hyphen and underscore) string that is collated with String.compare().

Again, I’m struggling to see the motivation. I believe that a universal scheme is impossible — it’s a circle that can’t be squared, especially when you try to encompass the versions used by Java releases like “8u66”. So if it’s not universal and it’s not to be adopted by JSR 376, what is the intended purpose?

Neil

> On 23 Mar 2016, at 20:10, Paul Benedict <pbenedict at apache.org> wrote:
> 
> Neil, I believe you're right regarding how JSR 376 will not define versions. David can speak for himself, but I didn't get the impression he is proposing a "de facto" way of what a version scheme is. His class just encompasses the many versioning schemes out in the wild so they can be parsed and inspected by a single class. I don't see any incompatibility with OSGi and Maven here, per se, since their schemes is just one of many. David's code does give a universal way to collate with these schemes, which I find appealing.
> 
> Cheers,
> Paul
> 
> On Wed, Mar 23, 2016 at 3:01 PM, Neil Bartlett (Paremus) <neil.bartlett at paremus.com <mailto:neil.bartlett at paremus.com>> wrote:
> Hi Paul and David,
> 
> You may consider this collation order intuitive, but it’s clearly incompatible with existing version systems; in particular I’m thinking of those used in OSGi and Maven.
> 
> I really don’t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context?
> 
> Regards,
> Neil
> 
> 
> > On 23 Mar 2016, at 18:53, Paul Benedict <pbenedict at apache.org <mailto:pbenedict at apache.org>> wrote:
> >
> > For any of the EG members observing this list,
> >
> > I find David's collating order acceptable and expected. I am not privy to
> > Reiner's particular discussion, but it is my opinion that 1.0 should
> > precede 1.0.0. Although both are numerically equal, one is more precise --
> > ambiguity should be first, precision last. I don't find this to be any
> > different than the alphanumerical nature of a phone book where A would
> > precede AA. That's not a perfect analogy but it gets my point across.
> >
> > Cheers,
> > Paul
> >
> > On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>>
> > wrote:
> >
> >> On 03/23/2016 09:20 AM, David M. Lloyd wrote:
> >>
> >>> I've gone ahead and written a new Version implementation that implements
> >>> the rules I've described.  It seems to work OK though I am having a hard
> >>> time running all tests locally due to some environmental problem that
> >>> I'm still working on, so I don't have a webrev yet.  But I do have a
> >>> diff that can be examined (and commented upon) at [1].
> >>>
> >>
> >> One oddity that springs up relating to numeric versions when not
> >> normalizing the version string in any way is that version segments leading
> >> zeros parse and sort strangely.  After fiddling around with various
> >> approaches, currently I've settled on this order:
> >>
> >> 1
> >> 1.0
> >> 1.1
> >> 1.00
> >> 1.01
> >> 1.10
> >> 1.11
> >> 1.000
> >> 1.001
> >> 1.010
> >> 1.011
> >> 1.100
> >> 1.101
> >> 1.110
> >> 1.111
> >>
> >> Wherein versions are sorted for length first, then for value.  However
> >> that might be counter-intuitive if your expectation is that (for example)
> >> 1.0 is equal to 1.00 or at least sorts immediately before or after it.  A
> >> good case could be made that versions should be normalized to strip leading
> >> zeros, and I believe the previous implementation did this (either
> >> intentionally or unintentionally) as an implementation side-effect.  The
> >> downside of normalization is the extra work and extra String being produced
> >> as a result.
> >>
> >> A third option would be to reject version segments with leading zeros,
> >> which prevents the problem from coming up and also avoids the extra copy
> >> work, making the "number" production look like:
> >>
> >>   number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal
> >> digit ? }
> >>
> >> Any thoughts on this would be appreciated.
> >> --
> >> - DML
> >>
> 
>