Kenney Westerhof wrote:
Richard van der Hoff wrote:
Hi,
Carlos Sanchez wrote:
Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven
Can you justify that with an example, at all?
What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.
For instance
<version>
<major>1</major>
<minor>2<minor>
<bug>1</bug>
<buildnumber>123</buildnumber>
</version>
The problem is basically that this simply isn't powerful enough to
cover all the various versioning schemes there are in the wild.
Suggesting forcing everybody to conform to your idea of versioning
isn't at all helpful; similarly imposing a complex mapping between
upstream and maven versions for a project is unattractive.
I agree. As i said in another mail, something like this could be used to
specify
a weird versioning scheme. Versions are ONLY needed for comparison,
nothing else, so that's
where proper parsing and comparing comes into play. Limiting freedom in
using version schemes just so we can compare them is not the way to go
IMHO.
Furthermore you don't leave any scope for extension such as might be
required for local modifications of a project.
Stéphane also suggested forcing a particular versioning convention on
everybody - the same argument applies.
Regarding Kenney's proposal: as discussed on #maven, all sounds very
sensible to me. I'm still fishing for, and failing to find, examples
of failures for projects where people invert the precedence of . and
-; however anyone doing that probably deserves what they get.
Still waiting.. ;) Did we discuss this one: 1.0-2.3 <=> 1.0-2-3,
which is newer? My algorithm would say 1.0-2.3.
I don't think it would be unreasonable to expect a project's maven
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping
through hoops to make this work may not be worthwhile.
True. But as others suggested, when project leads are replaced, version
schemes
may change also. Though I think that if that's the case, then they'll
probably
stick to the current scheme until a final (bugfix) release has been
made, so
you will probably never find 1.0alpha2 <=> 1.0-alpha-3, but rather
1.0alpha2 <=> 1.1-alpha-2. I think this is a limitation we could easily
impose.
Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ?
What happens when we've released an alpha, but want to continue
hacking on SNAPSHOTs before releasing another? we want SNAPSHOT
between rc and ga, no?
Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of an
alpha
or beta or rc has been released yet. I'd say:
1.0-SNAPSHOT < 1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... <
1.0-rc1 < 1.0-rc2-SNAPSHOT.
Snapshots also have to be possible before the first alpha (which is
pretty common to do),
and if we allow SNAPSHOT's to be present everywhere (and use it as a
qualifier, so:
SNAPSHOT < alpha < SNAPSHOT < beta <..), we can never compare with
snapshots.
From experience I'd say people start out with 1.0-SNAPSHOT, and later
do 1.0-rc-1. Then before
the ga is released, they don't revert back to 1.0-SNAPSHOT (or
shouldn't, i've seen people do it). This
produces unpredictable results.
maven-site-plugin anyone? :)
Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
implementation, 2.0.1-xyz is newer than 2.0.1."?
No it doesn't. The current implementation assumes 2.0.1 is newer than
2.0.1-xyz.
To quote Barrie Treloar who quoted a book:
quote BBWM page 60: "It is intended that the qualifier indicates a version
prior to release"
thus 2.0.1-xyz < 2.0.1 is correct.
The -INTERNAL was always meant to be a qualifier.
Thus: 2.0-SNAPSHOT < 2.0-INTERNAL < 2.0
I'm missing some context here, but 'xyz' is not a KNOWN qualifier. Our
qualifiers
are 'alpha', 'beta', 'rc, 'ga', 'sp'. If it's a random string, and we
don't call it a qualifier,
it could well mean a newer version.
The problem is where to place strings that are unknown qualifiers:
alpha < beta < rc < ga < (here?) < "" < (here?) < sp < (here?)
I may just be misunderstanding your explanation, but if you could
clarify what exactly happens when a given component isn't present, and
for unrecognised qualifiers, that would be useful.
Right now: if a component is not present, in the case of:
integer <=> null: integer==0 ? 0 : 1 (this fixes '2.0' <=> '2' which is
0, and 2.1 <=> 2 which is 1)
list <=> null: does a compare for list <=> [empty list], which
finally results in either integer <=> null or string <=> null
string <=> null: see the 'alpha < beta' list above.
Use the empty string instead of null, then compare
string <=> "". So when comparing
1-alpha with 1, this is the same as comparing
"1-alpha" and "1-". Which one is newer
depends on wheter 'string' is listed before or after
the "" in the list above.
Algorithm for string <=> string:
Construct a string for the left hand side, and one for
the right hand side, and compare those
lexically:
construct a string: if the string is a known
qualifier, use the index in the qualifier list (alpha=0,
rc=2 etc), otherwise concat the size
of the qualifier list (6) and the string ("6-string").
So, "alpha" <=> "" -> '0' <=> '5' = -1
"foo" <=> "alpha" -> '6-foo' <=> '0' = 1
(but like I said, this is up for debate.
-- Kenney
I've found the current scheme quite limited, and certainly capable of
producing unexpected results, so I'm definitely in favour of making
some changes here.
Best regards,
Richard
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
