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

[Ian Young]

On 2 Nov 2013, at 08:44, Tom Zeller <tzeller at dragonacea.biz> wrote:

> Rename java-parent-project-v3 to java-parent-project

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

I had thought we had decided not to do a revamp this time round, in order to save time, but it's a long time since the last discussion and I could be misremembering.

You need to clarify, though, whether you're talking about just the artifactId or both the artifactId and the project name.

I assume the repository will remain java-parent-projects.

> and tag as version 5.
> 
> 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.

Branching strategy, to my mind, is about what happens in the repository and less about version numbers. I'm fine with late branching in the repository.

I'm not so happy with the half-way house you're proposing between "proper" version numbers as used by the rest of our projects, and the whole number scheme we've previously used for parent projects.

If we're going to move towards a branching strategy for parent projects, and therefore use multi-component version numbers for them at any point, I think we should use semantic versioning for the artifacts as is our settled policy for everything else. That would imply the version becoming X.0.0 for some value of X; I'm agnostic as to whether that should be 2, 5 or 7 but I do not think we should use something that looks like an incrementing number from the previous scheme.

Actual proposal: tag/release as 5.0.0, then revert the POM version to 5.1-SNAPSHOT for continuing development. (I think this is consistent with our versioning policy; of course I could be wrong on some of the details)

> The main difference between parent-v2 and parent-v3 seems to be the
> version of the Java compiler,

The Java compiler version plus a corresponding development environment.

> which could be overridden lower in the POM hierarchy, if we wanted a single parent,

I think that would turn out to be harder than you imagine. Java compiler transitions tend to be where we rip out surrounding tooling which isn't being maintained, for example. 

> and eventually Java 6 will be EOL anyway.

Java 6 EOL is not the criterion, the EOL of all of *our* projects which are dependent on that parent is.

> 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.

Me too. I definitely do not think that we should be doing anything to change how the V2 parent works right now.

> 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.

Hard to tell, my brain has started to hurt at this point.

> 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 ;-)

Or more formal minuting of decisions.

	-- 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/20131102/13705b61/attachment.bin