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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
