Best practice to handle customer-facing versions and issues vs. internal builds and & issues

[M_S_]

My small organization has been using JIRA for tracking changes (new features, improvements, defect corrections) as part of our software development. I am however struggling with the (non-technical) aspect of how to properly manage versions/releases and issues and would appreciate opinions and suggestions from experienced JIRA users.

Our software uses the typical 4-digit version scheme: the first 3 digits denote the actual "version" (e.g. 3.1.4) - which we specifically choose/determine - and the last digit is the build number (e.g. 1145), which gets automatically assigned by the CI environment.

Internally multiple builds for a particular release exist (e.g. 3.1.4.1145, 3.1.4.1146, ...) but only one will ever get shipped to the customer (e.g. 3.1.4.1146), after which we would continue with the next version (e.g. 3.1.5 or 3.2.0, ...). That way, the build number itself is actually not relevant outside our organization.

When it comes to JIRA, we opted for tracking our versions in JIRA as "releases" only, but do not currently enter each individual build. So JIRA currently only knows 3.1.2, 3.1.3 and 3.1.4.

Now, we can easily enter and track issues that relate to a previously released customer-facing version (e.g. affects version = 3.1.3) and have been addressed in a new customer-facing version (e.g. fixVersion = 3.1.4). This makes compiling a list of what was changed between particular customer-facing versions quite easy.

However, we are struggling with maintaining issues that come up between internal builds only. For example, while working on the upcoming version 3.1.4, build 1145 would exhibit an issue that did not exist in the last release (so was introduced during development) and needs to be fixed. We currently have no good way of documenting this with the above-mentioned approach - since the build does not exist in JIRA.

Long story short: is there a best-practice approach for how to handle/differentiate between actual customer-facing versions and internal builds as well as customer-facing issues vs. internal-only issues?

If we enter versions in JIRA only, there is no good way to track "internal" issues that apply to a particular build only.

If we track each build in JIRA, then that creates a whole suite of follow-up problems: (a) the build number is not predictable, (b) customer-facing issues are split across multiple JIRA releases, making it harder to see what was actually changed from a customer's perspective.

[Earl McCutcheon]

Hello @M_S_ ,

We have the following Blog post that goes into more detail on managing release versions in Jira that I recomend checking out:

• Learn how to use versions in Jira Software

But the main thing is that per project you are going to have one set of releases and wont be able to break it out into a build category of sub releases, so the best thing to do would be break out the builds into a dev project and track the main release in a separate project.

Check out the following thread it offers up some good suggestions for this, including splitting the dev work and overall project tracking between two projects, and notes some add-on apps that could also help out as well:

• https://community.atlassian.com/t5/Jira-questions/How-can-I-use-Versions-to-do-release-planning-across-multiple/qaq-p/355240

in addition to the add-ons mentioned above if you use Advanced Roadmaps as well or wanted to look into it there is a cross project release feature in the app that could help out as well in syncing up the releases between a dev project for the multiple builds and the main release for the customer visible project, more details here:

• Creating and configuring cross-project releases

Regards,
Earl