Richard van der Hoff wrote:
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.
Correct;
1-0-1.596 = [1, [0, [1, 596]]]
1-0.193 = [1, [0, 193]]
comes down to comparing [1, 596] with 193.
It's easily changed, though I'm not sure what the impact would be.
And you would deserve it, definitely ;)
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 totally agree.
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.
Well, we usually release say 1.0-SNAPSHOT first a few times, then
1.0-beta-1-SNAPSHOT,
then 1.0-beta-1, etc.
SNAPSHOT means 'working towards version'. It should be a suffix to the next
final
release made. So if your next release is 1.0-alpha-1, use 1.0-alpha-1-SNAPSHOT,
not 1.0-SNAPSHOT.
But then again, maybe there's no problem in using snapshots everywhere - you're
only
interested in the latest one anyway, and this could be a SNAPSHOT from
pre-1.0-alpha-X,
or a SNAPSHOT from pre 1.0. Guess it's not a problem after all.
I think the SNAPSHOT qualifier should be removed from my implementation, since it's not really
a qualifier. SNAPSHOT versions are resolved from the repository first anyway.
With this in mind, comparing 1.0-SNAPSHOT with 1.0-alpha-1 would cause problems.
Depending on wheter 1.0-SNAPSHOT is a pre-alpha-1 release, or a pre 1.0 release,
it would be older or newer.
Maybe whenever a 1.0-SNAPSHOT is encountered, it should also resolve to the
latest 1.0-*
version released.
For instance, we have in the repository, in order of deploying:
- 1.0-SNAPSHOT
- 1.0-alpha-1-SNAPSHOT
- 1.0-alpha-1
- 1.0-SNAPSHOT
- 1.0-rc-1
Then 1.0-SNAPSHOT should resolve to 1.0-rc-1. This requires some work on
snapshot resolution,
but SNAPSHOT in a dependency means 'get me the latest version' (whereas SNAPSHOT in the
project's version tag means: 'working towards').
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 :).
Depends on the project's release management. At maven we use a few different
schemes.
This is once I've seen: once we release 1.0-alpha-1, the pom is updated to
1.0-alpha-2-SNAPSHOT. When no alpha-2 is needed, the pom is updated to beta-1-SNAPSHOT.
Same applies for the final release - when no 1.0-beta-X is planned, the pom is
updated to 1.0-SNAPSHOT
(1.0 being the final beta, if we don't use rc's).
Some even use this scheme:
trunk always has 1.0-SNAPSHOT; when alpha-x is released, a branch is created
for alpha-(x+1).
When no more alpha's are released, a beta is released, creating a new branch
(or updating the alpha branch).
In the mean time, both alpha/beta snapshots and 1.0 snapshots are published
(which could cause some serious
headaches with the current implementation).
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.
That's what i'm proposing, yes. It conflicts with to the current implementation.
The problem with the current implementation is that '1.0-abc' is considered
older
than 1.0-alpha1, but 1.0-xyz is considered newer than 1.0-alpha-1. This lexical
sorting,
together with qualifier length and prefix checking, is not intuitive.
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
