db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kalén <mka...@apache.org>
Subject Re: JIRA Release Management
Date Thu, 07 Apr 2005 09:54:33 GMT
Armin Waibel wrote:
>> However, this requires that we start specifying explicit release 
>> numbers instead
>> of the 1.0.x/1.x (which seems to work against the purpose of 
>> release-numbers in JIRA).
> 
> So at the latest the correct release-number have to set when the issue 
> will be closed?

You were right Armin, it seems that closed issues can not be reassigned
a different version (which is good since closed should be == read-only).

I have created version for OJB 1.0.0, 1.0.1, 1.0.2 and 1.0.3 with
approximate release-dates taken from the ojb-user announcements.

The releases 1.0.0-1.0.2 are "archived"/greyed out, but I left 1.0.3
as released since I think it is good to keep the last released version
open so that bug reports can be attached to it.


There is a "merge release" function in JIRA which will move all issues
from one version to another one and delete the first version afterwards.

I think a good way of assigning JIRA version numbers is:

*) if a user is reporting an issue on a released version (currently 1.0.3),
	select that exact version for the issue

*) if a user or develper is reporting an issue for a CVS branch,
	use temporary version "1.0.x CVS" and "1.1 CVS" for the issue

*) when a release is pending, eg 1.0.4,
	1. create a new JIRA version 1.0.4 (can be done long before release)
	2. set approximate release date (can be done long before release)
	3. merge/delete "1.0.x CVS" to 1.0.4 in JIRA (just before release)
	4. release 1.0.4 in JIRA (will "lock" version and create changelog)
	5. archive last release (1.0.3) in JIRA
		(no longer possible to report 1.0.3 bugs after 1.0.4 release)
	6. create new "1.0.x CVS" version in JIRA
	7. restart whole procedure from 1 with version number++ :-)

Does that make sense?

Disclaimer (TM) - some facts are based on my JIRA assumptions,
that could very well be wrong. ;-)

Regards,
  Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message