db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: JIRA Release Management
Date Thu, 07 Apr 2005 12:08:57 GMT
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: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
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