Alternative Version implementation
Paul Benedict
pbenedict at apache.org
Wed Mar 23 21:11:17 UTC 2016
Yes. :-)
Cheers,
Paul
On Wed, Mar 23, 2016 at 4:04 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:
> I guess you mean more like this:
>
> 1
> 1.0
> 1.00
> 1.000
> 1.1
> 1.01
> 1.001
> 1.10
> 1.010
> 1.11
> 1.011
> 1.100
> 1.101
> 1.110
> 1.111
>
> where the numeric value is most significant and otherwise the sort is by
> length ascending?
>
> On 03/23/2016 03:57 PM, Paul Benedict wrote:
>
>> David, I accidentally missed something first time around. I am happy
>> Neil pointed it out (thank you). This is actually the order I was
>> expecting. I am treating numbers as numbers, with more precision being
>> greater in the collation.
>>
>> 1
>> 1.0
>> 1.00
>> 1.000
>> 1.01
>> 1.001
>> 1.010
>> 1.011
>> 1.100
>> 1.101
>> 1.110
>> 1.111
>> 1.1
>> 1.10
>> 1.11
>>
>>
>> Cheers,
>> Paul
>>
>> On Wed, Mar 23, 2016 at 3:44 PM, Neil Bartlett (Paremus)
>> <neil.bartlett at paremus.com <mailto:neil.bartlett at paremus.com>> wrote:
>>
>> Thanks David, I should have awaited your reply before responding to
>> Paul. See that email for more specifics on OSGi versions.
>>
>> I wasn’t implying anything about agreement with Remi Forax or
>> anybody else. In this case, my question was really just a question.
>> However I am skeptical about the practical feasibility of creating a
>> version scheme that can bring together all the existing practices.
>>
>> I am also very concerned with your the suggested collation order in
>> which 1.1 sorts before 1.00. This is subjective of course, but I
>> find it highly counter-intuitive. If the segment looks like a number
>> then it should act like a number, unless all segments are explicitly
>> defined as strings with alphanumeric sorting.
>>
>>
>> Neil
>>
>>
>> > On 23 Mar 2016, at 20:23, David M. Lloyd <david.lloyd at redhat.com
>> <mailto:david.lloyd at redhat.com>> wrote:
>> >
>> > The OSGi specification allows (from what I can tell) arbitrary
>> strings for the last segment and that is definitely incompatible with the
>> notion of these more general version rules... this is the only difference I
>> can find though, and many practical examples of OSGi versions should
>> continue to work, which at least yields the possibility of moving forward.
>> Are there additional scenarios you can identify?
>> >
>> > Maven on the other hand does not really have a specification, so I
>> just referred to of existing examples and they seem to function as expected.
>> >
>> > The work I'm doing is intended as something of a bridge between
>> what is in place now (a structure which is designed for use in the JDK and
>> which implies a strict syntactical and semantic format which is
>> incompatible with a very large number of existing schemes and version
>> numbers) and a way to allow each layer to impose its own policy. But I
>> think what you are implying is that you share my interpretation of Rémi
>> Forax's opinion that a plain string is a better version identifier, with no
>> sorting/comparison or validation logic, putting 100% of the responsibility
>> for interpretation and validation of the version string to the layer which
>> defines the module. Is my understanding of your position correct?
>> >
>> > On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) 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
>> >>>>
>> >>
>> >
>> > --
>> > - DML
>>
>>
>>
> --
> - DML
>
More information about the jpms-spec-observers
mailing list