You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Use case follows. How do you folks deal with this?
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 !
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)
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)
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.
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.
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.
The problem with your view is that
Why is so hard to understand this?
It's not hard to understand that you have a broken process. Why are your developers misusing the field?
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 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.