[#JRA-10619] Freeze release

JIRA

Freeze release

Created: 17/Jul/06 09:14 AM Updated: 14/Mar/08 12:47 AM

Component/s:

Time Tracking, Workflow

Affects Version/s:

3.6.2

Fix Version/s:

None

Time Tracking:

Not Specified

File Attachments:

vincent.keunen.vcf (0.3 kB)
2.

vincent.keunen.vcf (0.3 kB)

Issue Links:

Duplicate

This issue is duplicated by:

~~JRA-14632~~ Version freezing

Participants:	Josh Goodall, Keith Brophy, Neal Applebaum and Vincent Keunen
Since last comment:	22 weeks, 5 days ago
Labels:

Description

« Hide

It would be useful to be able to "freeze" a release, ie to put it in a state where no new issues can be assigned to a release (when discussing with a client, they tend to agree on a number of features/fixes to put in the next release, then over time they want to add and add and add... making the release overflow with issues (if the release date has been set)). The best would be that jira prevents adding issues, but this is probably more involving. If it could at least show clearly on the release (version) pages and maybe when selecting the version when assigning, then it would already be a first step.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Keith Brophy added a comment - 18/Jul/06 01:52 AM

Hi Vincent,

I think the Archiving functionality should address your requirements:

http://www.atlassian.com/software/jira/docs/latest/version_management.html#Archive+a+Version

Once a version is archived, issues associated with the archived version cannot be unassociated with this version. Further, no other associations can be made with the archived version.

Regards,
Keith

[ Permlink | « Hide ]

Vincent Keunen added a comment - 19/Jul/06 09:49 AM

Thanks for your feedback! I'll look more into this option.

–

Vincent Keunen, Ir
Manex, rue Wagner 127, BE-4100 Boncelles, Belgium (map
<http://www.manex.be/ndpages/misc/manex-directions.html>)
web: manex.be phone: +32 4 3303730

Reclaim Your Inbox (and reduce virus spreading)!
http://www.mozilla.org/products/thunderbird

[ Permlink | « Hide ]

Neal Applebaum added a comment - 19/Jul/06 12:55 PM

Just be careful.. there are a few unresolved bugs with respect to archiving, although I do use it.
~~JRA-9923~~, JRA-8934

[ Permlink | « Hide ]

Vincent Keunen added a comment - 20/Jul/06 11:36 AM

Well... If I "archive" a version, I can not see it anymore in the "fix"
popup of create new issue, which is good. It's close to "freezing" the
release.

However, there are several problems:

the archived version does not appear in the "affects" popup menu,
which I believe to be wrong: I should be able to create issues for an
unreleased version and mention that the issue affects an archived
version (in the sense of "frozen")
the archived version disappears from the roadmap, which is annoying
because it's exactly the version we are workiing on, close to be
released (that's why we froze it)

I also noticed some behaviors that don't seem logical to me
(independently of archive):

Released versions still appear in the "fix" popup menu of "create
issue", so I can still add issues to a released version!? (maybe you
think that one can add, after the release, the information that a
"forgotten" issue was indeed fixed? is that the reason?)

So in summary, I think archive does not do what freeze should do. Is
there a way to add that frozen status in our jira by some config magic?

What I think should be improved in Jira (if I understand correctly):

one should not be able to add an issue to a released version (remove
released versions from the "fix" menu)
one should be able to set an "affects" to an archived version (add
archived versions to "affect" menu)
one should not be able to add an issue to a frozen version (remove
frozen versions from the "fix" menu)

What do you think?

–

Vincent Keunen, Ir
Manex, rue Wagner 127, BE-4100 Boncelles, Belgium (map
<http://www.manex.be/ndpages/misc/manex-directions.html>)
web: manex.be phone: +32 4 3303730

Reclaim Your Inbox (and reduce virus spreading)!
http://www.mozilla.org/products/thunderbird

[ Permlink | « Hide ]

Neal Applebaum added a comment - 20/Jul/06 01:24 PM

I will add only one comment ... I do have a need to set an issue's Fix for version to a version that has already been released. This happens when we release it, and a few days later some emergency comes up and we need to do a Hotfix with the same version code. I suppose I could unrelease it first, but anyway that's my use case.
In the meantime, would it help if you edited your frozen release descriptions to "* Frozen do not use ...*", or something similar. At least it would help the end users.

[ Permlink | « Hide ]

Vincent Keunen added a comment - 16/Aug/06 03:54 AM

OK for your rationale behind being able to add issues to a relased version - I agree (although I think it will get very confusing soon to have several different software applications with the same version number; I would either augment the "minor release number" or add a "build number" to make the two software applications clearly distinct - and I would point the new "hot fix" issues to the new version. But this is indeed a use case, so let's close this part of the issue.

[ Permlink | « Hide ]

Vincent Keunen added a comment - 16/Aug/06 03:56 AM

For the rest (the real "frozen" concept), I think my comments here still hold and capture pretty well the functionality we are missing.

Feel free to ask for more info.

Cheers

[ Permlink | « Hide ]

Josh Goodall added a comment - 14/Mar/08 12:47 AM

Adding my vote - our release managers have requested the ability to freeze a version prior to release, with roughly the following semantics:

Version still appears on roadmap but marked "frozen".
Version still appears for bug reports (i.e. the Affects Version/s field still lists this version)
Version no longer appears for the Fix Version/s field.

We don't care if the Fix Version/s field behaviour is enforced; for us, it's enough of a difference to simply omit a frozen version from the selection list.

Pretty sure I can't develop this as a plugin, since it's a modification to ManageVersions.jsp & co.