On 10/10/2013 03:31 PM, James Carman wrote:
We definitely need to make sure our naming scheme will work with maven
properly. Hopefully commons-foo:1.0 would supercede
commons-foo:1.0-M1. Again, I really don't care what we call it, as
long as we manage expectations and don't dork up maven.
Since Maven 3+ there is now a reasonable and predictable handling of such
versioning, including doing 'the right thing' for the commons-foo:1.0-M1 example.
See [1] (which is an old wiki proposal which since has been implemented) and [2]
for the exact rules, which I'm copying below for convenience.
From [2]:
Features:
- mixing of '-' (dash) and '.' (dot) separators,
- transition between characters and digits also constitutes a separator:
1.0alpha1 => [1, 0, alpha, 1]
- unlimited number of version components,
- version components in the text can be digits or strings,
- strings are checked for well-known qualifiers and the qualifier ordering is
used for version ordering. Well-known qualifiers (case insensitive) are:
- snapshot
- alpha or a
- beta or b
- milestone or m
- rc or cr
- (the empty string) or ga or final
- sp
Unknown qualifiers are considered after known qualifiers, with lexical
order (always case insensitive),
- a dash usually precedes a qualifier, and is always less important than
something preceded with a dot.
[1] https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
[2]
http://maven.apache.org/ref/3.0.4/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
On Thu, Oct 10, 2013 at 9:25 AM, Ate Douma <a...@douma.nu> wrote:
On 10/10/2013 03:00 PM, James Carman wrote:
On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:
I think "milestone" releases works if you have a clear development
plan and schedule. I've never seen it be the case in Commons. Calling
"releases" to Maven and dist, Alphas and Betas make more sense for us
IMO.
I don't care what we call it. They key is that we set up the
expectation with our users. If you use this release, do NOT use it in
production code. It is not "supported", meaning we aren't going to
fix bugs in that alpha version if we have already released its
subsequent full release version (or a subsequent alpha).
Indeed and agreed.
I also don't care if its called milestone or alpha or whatever.
But we already have explicit wording for milestone releases [1], also
clearly stating such releases are not supported.
So I'm actually only asking *confirmation* to use already established rules.
[1] http://commons.apache.org/releases/versioning.html#Milestone_Releases
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
