Versioning parent projects in JIRA ?

[Ian Young]

On 17 Sep 2013, at 05:14, Tom Zeller <tzeller at dragonacea.biz> wrote:

> Do we have consensus that JPAR versions should be of the format "V2.1"
> and "V3.1" ?

That's certainly not how JPAR versions have been up to this point; instead, they have always been given simple numeric version numbers ("1", "2", etc.).  I think the original pre-split version of the parent project went up to "4"; the V2 parent project release we did as part of the recent IdP and XmlSecTool release was tagged as "1".  The V3 parent project has never been released.

There's also some mention of this convention in the "locking" scripts, but I don't see anything which would make them break if we moved to a different convention.

I personally find the current situation confusing.  I suspect we should have thought more about this when we split the original single parent project, but didn't because we weren't expecting to do anything on the V2 line ever again.  That's just a suspicion, though, maybe Brent or Chad remember the actual reasoning.

I think I'd be in favour of moving to more conventional versioning for the parent projects along the lines you suggest.  Unless, of course, someone can remember a critical reason why we have to stick with the current convention, and we document it more clearly than we have to date.

> In general, I think we will need "duplicate" JIRA issues corresponding
> to the v2 and v3 parent projects, since I do not believe it is
> possible to assign more than one version to a JIRA issue. For example,
> we might need a "Bump dependencies" task with two sub-tasks, one for
> v2 and one for v3.

Yes, it's hard to know what's going on in that section of JIRA because the versioning doesn't distinguish between the V2 line and the V3 line.  I had assumed that we were going to have the versions track, but then the V2 parent project was released as version "1" so things are now a little inconsistent.

I guess we could continue to take the view that as nothing will ever happen on the V2 line again that its version number is irrelevant, but having seen that assumption proved wrong once makes me wary of making it again.

	-- 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/d073be35/attachment.bin