Kenney Westerhof wrote:
Richard van der Hoff wrote:
Hi,
Carlos Sanchez wrote: 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 we discussed exactly that. I think your algorithm is
probably right here. However, you've now helped me find the problem I
was fishing for. My imaginary project separates versions with - and
build numbers with .; so I have
1-0.193
1-0.204
1-1.897
Oops! I need to release a bugfix to 1-0: 1-0-1.596
With your algorithm, we have (I think) 1-0-1.596 < 1-0.193, which is
wrong for my (crazy) versioning system. But, as I said, I deserve what I
get for doing this.
There will always be some corner case we don't quite cover correctly; I
don't think we should let this worry us or act as an argument against
improving the status quo, provided we get most sane cases covered. We
just need to make sure the exact algorithm is documented :).
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.
Agreed.
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.
SNAPSHOT is a bit special anyway... If we have alpha < beta < SNAPSHOT <
ga, then people who want a SNAPSHOT will get the last snapshot before
the main release (regardless of the presence of alphas), and people who
don't will get the latest non-SNAPSHOT? I don't quite understand what
you mean here.
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.
So your recommendation is, once you want to make the final release, to
go straight from 1.0-rc-N-SNAPSHOT to 1.0, without ever releasing
1.0-rc-N (and similarly for transition into alpha, beta and rc stages)?
That's fine, provided it's documented :).
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.
So '' < unknown(lexical sort) ? Anyway, you say this is up for debate, fine.
--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
