Versioning parent projects in JIRA ?

[Ian Young]

I seem to be getting the mail for this thread delayed, and in the wrong order.  Hopefully this will still make sense.

On 17 Sep 2013, at 15:56, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> That's a valid point, we'd be stuck creating a new one on every major
> version, potentially. Not sure I like that idea.

The version number of the parent POM, to me, isn't necessarily connected with the versions of projects which depend on it.  The parent POMs really parent families of projects with different environmental constraints, in particular the version of Java they require.  So the "V2" family is Java 6 stuff and includes the V2 IdP but also XmlSecTool V1.  The "V3" family is Java 7 based and includes the V3 IdP but also the MDA.

A hypothetical IdP V4 might be fine with the V3 parent POM during development until, say, we decided to jump to Java 10.  At that point I'd expect us to come up with a V4 parent and migrate things across.  But the V3 parent should still be there, and potentially maintained, as long as any other project depends on it, i.e., until they can also migrate.  Just because the IdP migrates to Java 10, doesn't mean that every other project dependent on the V3 parent must do so at the same time.

> Also, I was assuming we would in fact need to branch the older parent
> version if we were maintaining an IdP V3 and V4 at the same time.

I'm not sure why we ended up with separate parent projects rather than branches when we wanted to separate the V2 and V3 parents. In some ways, it's the obvious thing to do, but we didn't go that route before and *my* assumption was that we'd make a separate V4 parent when required.  The downside, of course, is that one might end up with multiple projects in which one is making essentially the same changes most of the time.

> Could we create JPAR2 to isolate the 2.x version and then alter the V3
> parent versioning going forward to include the major and minor?

If we stick with the integral versions, I think we definitely want to split the JIRA structure to avoid cranial implosion.  I care less about the naming, but JPAR2 and JPAR3 fit better with the description I gave above.  I could live with JPAR for the "current" JPAR and JPAR2 for the V2 parent, but I don't think it is optimal: as above, I think we *would* want to create a V4 parent POM if and when we want to create a family of projects dependent on a new environment, as it's the parent POM that encapsulates all of that.  And I definitely don't want to make the assumption that we can just decide one day that the V3 parent POM will just require Java 10, unless there's only one product underneath.  Which there may be, of course, but there may not.

> We *could* also just embed this in the Jira version, and you can assign
> multiple affected and fix versions to a bug. I think you implied that
> wasn't possible but it is.
> 
> But it's kind of hacky, because you have to embed important info in the
> version string.

If on the other hand we move to non-integral versions on the parent projects then maybe it can all fit in JPAR without too much trouble.  Being able to enter just one ticket for a change that needs to be applied in all parent projects would be the big upside.

	-- Ian



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