Use case follows. How do you folks deal with this? * I release v1.0 in JIRA which sets it to "Released". * To prevent v1.0 from being chosen on another issue's Fix Version, I move v.1.0 to "Archived". * A few days later, I get a bug reported and determine it is affected in v1.0. But, the dropdown for Affected Version excludes v1.0 (presumably because it's archived). Why? I can see not being able to choose a Fix Version of 1.0, but I ought to be able to choose an archived version as the change set where the issue is discovered....I feel we need an interim state of a version....something like Unreleased, Released, Static, Archived. "Static" or whatever could be used to disallow its use as a fix version, but allow its use as an affected version.

I don't think your understanding this correctly. It's JIRA that is allowing developers to update the version after it's been released. It's not a process issue. That is a defect or bad design of the tool. Anyways, I found a workaround for this that requires installing a Behavior script in JIRA that kind of resolves this problem for the Affects Version field. But it doesn't seem to work for the Planned Release field. Argh!! Anyways, I shouldn't have to do this to begin with. JIRA should offer a default behavior and know how to manage the two version fields when a version is moved to the Release or Archive states... These are their out of the box fields, not mine. JIRA should automatically lock it down and hide the release in fix versions field. Otherwise it's pointless to even have the Un-Released, Released and Archive states to begin with? This is an incomplete design.

Sorry to sound harsh, but you actually stated that you have a broken process with: "after" the version has been moved to "RELEASE" developers can still add more JIRAs to a released version that has already been released. Which is wrong and useless. I completely agree that it's the wrong thing to do, and useless, if your release process includes a firm "this has been delivered, so you should not be adding to it" line somewhere. But If your process was right, developers would not be doing that (mostly by not feeling any need to)

I have developers that think they can do whatever they want. Our process is NOT broken... JIRA is broken and should allow me to set the policy and NOT the developer.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why can't we choose an archived version as "Affected Version"

Paul Alexander

Use case follows. How do you folks deal with this?

I release v1.0 in JIRA which sets it to "Released".
To prevent v1.0 from being chosen on another issue's Fix Version, I move v.1.0 to "Archived".
A few days later, I get a bug reported and determine it is affected in v1.0. But, the dropdown for Affected Version excludes v1.0 (presumably because it's archived). Why? I can see not being able to choose a Fix Version of 1.0, but I ought to be able to choose an archived version as the change set where the issue is discovered....I feel we need an interim state of a version....something like Unreleased, Released, Static, Archived. "Static" or whatever could be used to disallow its use as a fix version, but allow its use as an affected version.

Accepted answers

All comments

Nic Brough -Adaptavist-

Don't do point 2 - archiving really is there to stop people choosing it at all. If it's the version in production, it's not really archived (although you do have a good point that you don't really want to pick it as a a fix version)

Ligia Merciu

Hi there,

Our customer's approach is this:

- There are 3 environments: dev, test, production

- When the development is ready, a (fix) version (V0.1) is released when deployed on the test environment

- Tests run, some bug detected and fixed in V0.2 which is also released and deployed on the test environment

- UAT passed on test environment, V0.1 and V0.2 are merged into V1.0 wich is released and deployed on the production environment

- V1.0 is archived to mark it is in production

- After a while, a production anomaly is detected; this should be a bug that affects V1.0

And here is the problem: one cannot select V1.0, because the option is no more available for affected versions, although we all know that bugs may appear in production versions

Do you have any clue on:

- how to make a different between versions released for tests purpose on tests environment and version released into production environment?

- how to mark a bug in a production version, if the version is no longer available in the list?

It would be a great help !

Nic Brough -Adaptavist-

If you want to report on bugs found in versions, do not archive the version.

You say "V1.0 is archived to mark it as in production" - no, no, no, that is absolutely the wrong reason for archiving a version. Archiving a version is for when you no longer want to report against that version (because it's a version you're not supporting or developing against any more)

Zhaolin Feng

I believe what really needed is:

* Allowing a version to be selected as "Affected Version"

* Preventing it to be selected as "Fixed Version"

Having a version archived, failed to full fill the above purpose.

Nic Brough -Adaptavist-

No, that's not what archiving versions is for. An archived version should not be needed to be added to old issues - you're not supporting it or working on it any longer, so there's no point.

stephen_landry

You use case is totally invalid.

I archive releases to block developers from changing releases that have already been released to customers. When I archive the release developer can no longer select old versions under affects versions. This is totally messed up logic.

This renders the archive feature as being totally useless when it removes the version from affects version which is exactly what I don't want it to do.

There should be an option to link affects version to fix version, or unlink the two fields so that they are independent from each other. The logic for the current implementation is insane.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

version

fix-version