version numbering inconsistency

[Ian Young]

On 7 Oct 2014, at 16:11, Cantor, Scott <cantor.2 at osu.edu> wrote:

> Not sure, I guess I thought so too. If we're assuming the next release
> would be a patch (2.0.1), then I think that's what it's supposed to be. If
> we decide it's 2.1, then we branch and the trunk is 2.1-SNAPSHOT.
> 
> So maybe the problem is just with the tools or an issue fitting that with
> this versioning strategy.

I think the bottom line is that our current versioning strategy does not match up exactly with all of the tools, or at least can be construed to be different (by which I mean, I think our document is ambiguous).

I'm not a great believer in using different conventions than your tools do, though, so if we had a decision to make I'd be suggesting that we change rather than expecting Maven to.

Here's a random document I found that talks reasonably comprehensibly about how Maven does things:

http://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm

Some highlights of that:

* "All versions with a qualifier are older than the same version without a qualifier (release version)." 

* Maven treats the SNAPSHOT qualifier differently from all others. If a version number is followed by -SNAPSHOT, then Maven considers it the "as-yet-unreleased" version of the associated MajorVersion, MinorVersion, or IncrementalVersion.

This directly implies that 2.0-SNAPSHOT must not be understood to follow 2.0 (not that there ever was one of those). However, adding in the ordering rules from

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

I think we can say that the rules are clear about giving you

   2.0-SNAPSHOT < 2.0 <= 2.0.0

and therefore

   2.0-SNAPSHOT < 2.0.0

So, I think that following 2.0.0 with 2.0-SNAPSHOT is definitely just wrong if we want to be compatible with Maven. Whether we need to say 2.0.1-SNAPSHOT, 2.1-SNAPSHOT or 3.0-SNAPSHOT is a different question.

In this particular case, though, I don't think that we need to thrash it out at that level. If people are happy with just making it 3.0-SNAPSHOT for now, that makes the issue go away for now.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20141007/16bef5b8/attachment.bin