java-parent-project-v3 -> java-parent-project : redux

[Tom Zeller]

I wondered why I was dragging my feet tagging upstream MDA
dependencies, and I remembered, here is my proposal :

Rename java-parent-project-v3 to java-parent-project and tag as version 5.

The main idea is to remove the version, the "-v3", from the artifactId.

Also, Scott had suggested versions of the form "Major.Minor", which I
am fine with, but because our existing parent POM versions are
monotonically increasing integers, I suggest we aim for "consistency"
with those releases and then prefer a late branching strategy,
branching to "5.1" when necessary. It seems common that other
projects, like Jetty, tend to use integer versions for the parent POM,
but the jetty-parent POM does not include dependency management, so
the comparison is somewhat apples-oranges.

The main difference between parent-v2 and parent-v3 seems to be the
version of the Java compiler, which could be overridden lower in the
POM hierarchy, if we wanted a single parent, and eventually Java 6
will be EOL anyway.

I suggest version 5 since we have already released versions 2, 3, and
4 of net.shibboleth:parent.

The versions in JIRA of JPAR would then match versions in the parent
POM, except for parent-v2:1, which is an acceptable outlier to me.

If we had followed this model instead of creating
java-parent-project-v[23], then net.shibboleth:parent-v2:1 would
actually be net.shibboleth:parent:5 and I would be tagging
net.shibboleth:parent:6. I think.

I should have been more prepared and brought this up on the call
yesterday. Apologies for dragging this out.

On the dev call where we did talk about this issue, the waters seemed
muddy enough that I dropped it. I guess we need longer calls ;-)

Thread references :

Versioning parent projects in JIRA ?
http://shibboleth.net/pipermail/dev/2013-September/002682.html

Parent POM major.minor version convention, 1 vs 1.0 ?
http://shibboleth.net/pipermail/dev/2013-September/002705.html