Ordering of versions

[Brian Pontarelli]

This should work even with large graphs. A single module can define its scheme based on some implementation class or "well-known named" scheme. The key is that 99% of Java devs will follow the standard implementation, which should be simple and cover the most common forms. 

My suggestions for the baseline form is:

<version> ::= <major> ("." <minor> ("." <patch> ("-" <extra>)*)*)*
<major> ::= digit
<minor> ::= digit
<patch> ::= digit
<extra> ::= digit | <cycle> digit
<cycle> ::= "alpha" | "a" | "beta" | "b" | "rc"

The order of the cycles would be:
	- Alpha
	- Beta
	- Release Candidate

The only cycle that I would contend isn't a good idea to allow is "GA". In my opinion a GA is the same as the version without the "extra" element. Therefore, an order would be:

1.0-A1
1.0-A2
1.0-B1
1.0-B2
1.0-RC1
1.0-RC2
1.0
1.0.1
1.0.2
1.1
…

-bp
On Nov 9, 2011, at 1:58 PM, David M. Lloyd wrote:

> Agreed 110% about version schemes.  Rather than trying to encompass all schemes, the version scheme should be dependent on the library implementation... in fact it may not even make sense to require modules to even have a version in all cases.
> 
> The Java module system must embrace the fact that there are many approaches to versioning, and while its default library implementation(s) may support a specific scheme, other schemes should be allowed.
> 
> On 11/09/2011 01:45 PM, Neil Bartlett wrote:
>> Right: there is no general way to tell the order of two versions
>> *just* by looking at the version strings. You need to know the scheme
>> that is force, and there are multiple possible schemes, some of which
>> are more sane and intuitive than others.
>> 
>> The Java 8 module system needs to choose a version scheme that is, at
>> the very least, totally ordered... otherwise the version string is
>> meaningless, and is just a part of the module identity. The next most
>> important concern is that the scheme should be intuitive with respect
>> to ordering, and follow the principle of least surprise. Next I would
>> suggest that the scheme should support sensible semantics for the
>> meaning of each version segment with regard to signalling the scope of
>> a change. The final concern might be compatibility with existing
>> practice, which essentially boils down to OSGi and Maven
>> (incidentally, I hear that these will be compatible in the next OSGi
>> specification revision, with the introduction of "negative
>> qualifiers".. basically the same as snapshots).
>> 
>> I would submit that Mark's description of the Jigsaw versions and
>> tokens, though I have not fully understood it yet, fails the intuition
>> test. That is unless my intuition has been distorted by 6-7 years of
>> OSGi.
>> 
>> Rgds,
>> Neil
>> 
>> 
>> 
>> On Wed, Nov 9, 2011 at 7:22 PM, Eric Johnson<eric at tibco.com>  wrote:
>>> Is it even possible to solve this problem with just a version string?
>>> 
>>> Maven and OSGi (currently) have incompatible version schemes. In some cases,
>>> what Maven would consider less than another version number, OSGi would
>>> consider greater (the "snapshot" problem).
>>> 
>>> The only general way that I can think of to solve this is to indicate
>>> somewhere with metadata which version string semantics are in effect, and
>>> apply those semantics within the scope of the indicated metadata.
>>> 
>>> -Eric.
>>> 
>>> On 11/9/11 8:02 PM, Brian Pontarelli wrote:
>>>> 
>>>> It seems obvious from your example that lexicographic is probably going to
>>>> cause issues and confusion. Perhaps it makes sense to define a set of well
>>>> know and commonly used names and the order they have. I would assume this
>>>> would be simple to get a majority on.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Nov 9, 2011, at 9:37 AM, mark.reinhold at oracle.com wrote:
>>>> 
>>>>> 2011/11/9 7:47 -0800, gnormington at vmware.com:
>>>>>> 
>>>>>> I see. How are the tokens of a qualifier compared? If they are compared
>>>>>> just like the initial part,
>>>>> 
>>>>> Yes.
>>>>> 
>>>>>>                            then that would be a numeric comparison for
>>>>>> numeric tokens, but what about non-numeric tokens like BETA and GA?
>>>>> 
>>>>> They are compared lexicographically, so BETA<    GA.
>>>>> 
>>>>>>                                                                    Are
>>>>>> tokens compared as strings if at least one of the tokens being compared
>>>>>> is non-numeric?
>>>>> 
>>>>> Yes.
>>>>> 
>>>>>> Or I can read the code if you prefer to send me a link. ;-)
>>>>> 
>>>>> 
>>>>> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/960eb03d1270/src/share/classes/org/openjdk/jigsaw/JigsawVersion.java
>>>>> 
>>>>> - Mark
>>> 
> 
> 
> -- 
> - DML