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

[Paul Alexander]

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

1. I release v1.0 in JIRA which sets it to "Released".
2. To prevent v1.0 from being chosen on another issue's Fix Version, I move v.1.0 to "Archived".
3. 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.

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

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

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

[Nic Brough -Adaptavist-]

That's not what archiving is for, your use case is completely invalid.

You should be flagging your versions as "released" to tell developers that something is in production.

Linking an affects version to a fix version is pointless, it tells no one anything of any use, and having independent versions is even less useful, it makes a complete nonsense of having any versioning system.

[stephen_landry]

The problem with your view is that

1. "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.
2. I have over 300 releases. I can't move any of them to archive because JIRA also removes the version from affects version. Now my combobox for fix version lists all 300 releases, which exactly what I don't want. I only want to display "ACTIVE" releases in fix version and the ability to select any prior release in affects version.

Why is so hard to understand this?

[Nic Brough -Adaptavist-]

It's not hard to understand that you have a broken process. Why are your developers misusing the field?

[stephen_landry]

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.

[Nic Brough -Adaptavist-]

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)

[stephen_landry]

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.