Martin Kal�n wrote:
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).


if you reopen an issue it's possible to edit all settings. I check this with OJB-13 and set affected versions 1.0.xCVS and fixed version 1.0.3.



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.


ok, then all bugs found in 1.0.3 release should use 1.0.3 or 1.0.xCVS as affected version flag and when closing an issue I chose the next release number (1.0.4 and all other affected versions) - right?




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)

do this automatic change the "fix version" flag of all closed 1.0.xCVS issues? If yes, this will be really great!



    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?


Sounds good, +1
It would be great if this how-to could be integrated into the upcoming "OJB release guide"


Armin


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]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to