On 12/19/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
I've seen projects switch back and forth... depends on who is in power at the time and what style they like. So it would be best if mvn would be able comprehend:1.0alpha2 < 1.0-alpha-3
I disagree. I don't think it will help maven users if we start implementing algorithms like this. Why don't we describe the standard way of specifying a version number? The examples kenney had provided in his previous email sound a good start to me. If one want to use another version numbering (such as your example above) too bad. Now at least he would be aware that version comparison might not work. We can't predit all scenario anyway. WDYT? Stéphane
--jason On Dec 18, 2006, at 3:41 PM, Barrie Treloar wrote: >> - don't use the current 4-digit limitation, but instead list with >> a random amount of entries >> - entries are separated by dots or dashes >> - entries are separated by transition to/from alpha to numeric >> - sub-lists are indicated by '-' >> - entries can be either: string, integer, or sublist >> - versions are compared entry by entry, where we have 3 options; >> * integer <=> integer: normal numerical compare >> * integer <=> string: integers are newer >> * integer <=> list: integers are newer >> * string <=> string: if it's a qualifier, qualifier compare, >> else lexical compare, >> taking into account if either is a qualifier. >> * string <=> list: list is newer >> * list <=> list: recursion, same as a 'top-level' version >> compare. Where one list is shorter, >> '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 2.0- >> alpha <=> 2.0.0 = -1 (2.0 = newer)) > > The edge cases around the examples like 1.0alpha2 and 1.0-alpha-2 are > bit beyond how I would use things so I can't really comment. However > I would expect a project to be self consistent so it doesn't really > matter if 1.0alpha2 is newer than 1.0-alpha-2, just as long as > 1.0alpha2 < 1.0alpha3 and 1.0-alpha-2 < 1.0-alpha-3 which the rules > cater for. > > Everything else seems reasonable and the examples appear to make sense > and parse the way I would expect things to work. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
