Using Version for release and intermediate builds

[uric]

Hi,

In a common development process of a s/w team we have a version that we plan to release to the public, and its our goal to complete it. So we set issues with the Fix Version set to that version.

Let's say that for example we plan a release called version 1.2.3, and we have 10 issues with Fix Version=1.2.3. So we prepare a build of that version and send it to QA. Now the QA team looks for all the issue under Fix Version=1.2.3 and tests them. By that we find some bugs and so we open Jira issues for that.

My question is how should we call the next build with those bug fixes?

• Giving it a different name, and there will be for sure a couple of version until QA completes? Then how should I track and gather all those versions that are related?
• Using the same version code (the same Fix Version)? Doing that we won't be able to tell for a bug on which build it's resolved. And if a bug appears on one of the intermediate version then how the QA tells the developer in which version build it can be found (how to properly mark the  Affects Version)?

[Yuri Lapin _Release Management_]

Hi Uric,

Very good question.

There is no silver bullet, but let me share pros and cons for different solutions from my experience.

The easiest is to keep single version (version 1.2.3) as you mentioned above, but the drawbacks are:

• you either have to constantly keep Unreleased version as you keep on adding scope
• or you add scope to Release version that's a slight anti-pattern
• but probably the biggest one is the fact you never know what's deployed where?
  • Details: I presume you have multiple environments. Starting from Dev, QA/Integrations, etc. In my case also few geo-distributed Production Environments.  Keeping single version does not help you understand whether the version you have on specific environment includes the latest fixes or not?

The most flexible option is to introduce a 4th digit (aka version 1.2.3.4) for service releases so you overcome the obstacles above. The disadvantage is:

• Jira has a flat structure of versions so your plain list will start to grow too fast and will become difficult to navigate. So you would need to have a good discipline of Archiving versions.
• There are some App that helps to create sub-version structure (aka Parent-Child relationships), Check it out. Maybe something helps.
• In our own App - Release Management & Roadmaps for Jira Cloud - we decided to take another approach and build an entity on top of Jira versions to represent Release. Thus you can package multiple versions, including service release into actual Release that's happening.

Hope this helps.

Cheers,

Yuri.