[Opendnssec-develop] RE: Project versions in JIRA

Sara Dickinson sara at sinodun.com
Fri Jun 8 15:24:22 UTC 2012

Hi All, 

Looking at JIRA today I can see there there is both a 1.4.0 and 1.4.0b1 version both with unresolved issues. (And a version 1.4.0a2 but with no issues against it.) I don't know how project (sub)versions were handled in the past with PT but I have seen the following type of approach work well in JIRA:

 - at the start of a new release create a version called e.g. 1.4.0a1 and use this throughout the development phase
 - when it is time to release the first alpha, create a version for the next release (e.g. 1.4.0.a2). Move all unresolved issue from 1.4.0a1 to 1.4.0a2 and release 1.4.0a1
 - repeat through beta and release candidates. 
 - if needed create (sub)versions in advance for issues that are allocated to those versions
 - when the full release is made then JIRA has the option of merging all the sub-versions into a 1.4.0 version to tidy things up.

This would mean that it would be way easier to use the built in functionality of JIRA in terms of generating change logs (completed issues to compare to the NEWS file) and roadmaps (lists of outstanding issues for a particular version) as we go through 'pre-releases'. It also makes it very easy to distinguish between released and development versions.

But... there are *many* other ways to do version management so all comments and suggestions welcome! I did read a little about using version hierarchies with greenhopper but it looks like this has some bugs and limitations and I like the simplicity of the above approach.



More information about the Opendnssec-develop mailing list