Jira - How to name a Jira release

Question

We have a Jira project which contains all issues for a single website. The website has several different components, such as the theme and several lambda functions. Each component has their own repository and is deployed separately from the others.

Confusion sets in when trying to figure out how to name each Jira release/version. We will be using semantic versioning, however, do we create a different version for each component? For example, should a history of releases for a project look like:

• Theme-Release-2.3.0
• LabmdaFuncA-Release-1.9.0
• LambdaFuncB-Hotfix-1.6.1
• Theme-Release-2.4.0
• LambdaFuncB-Release-1.7.0

Or should all of the components share the same release version?

• Release-1.4.0 (contains updates for Lambda Function A)
• Release-1.5.0 (contains updates for Lambda Function B)
• Release-1.6.0 (contains updates for the Theme)

Also, a related question: Should the repository version match the Jira version?

Answer 1

The answer for this question is, at the end, dependent on how you'll use this information. So, why do you have versions at all? You have to think about this before asking how to manage versions.

Think a bit longer. Get the answer.

Got it? Ok.

(Disclaimer... this answer may NOT fit your need)

From a project management perspective, what you usually want to know is what has been released when. Understanding a 'release' as what versions your application had at a specific point in time, it makes sense to have releases component-agnostic.

In my project, we have around 90+ components and UAT releases every week - after a few cycles, they go to PROD. How do we track them? There's a weekly release ID, and we have (yes, I know, it'll sound cumbersome) Confluence entry where we list all the component-specific versions present on this release... and in this point, our approach diverge from the one proposed by Alexey, as each component has a specific build number regardless of the release.

Our Confluence would look like this (in bold, the component changes at each iteration):

Release 1.0.0:

• Theme-Release-2.3.0
• LabmdaFuncA-Release-1.9.0
• NewComponentA-Release-1.0.0

Release 1.0.1:

• Theme-Release-2.4.0
• LabmdaFuncA-Release-1.9.0
• NewComponentA-Release-1.0.0
• NewComponentB-Release-1.0.0

Release 1.0.2:

• Theme-Release-2.5.0
• LabmdaFuncA-Release-2.0.0
• NewComponentA-Release-1.0.0
• NewComponentB-Release-1.1.0

Answer 2

I've been placed to the same circumstances for years. And the approach of having the versions for each particular component showed poor efficiency (at least in my project) due to Jira specific.

Jira versioning is well-designed when you version the project as a whole and does not support component versioning. So the best solution is to consider migrating to some other task management systems or consider managing the components each in its separate project.

Your approach would be okay unless you have more-or-less large release history. The more releases you will complete the more difficulties you will face when you will need to analyse the things done on some rather large extent.

Repository versions should match the jira versions. This will let you easily refer to a proper build in repo having the version of an item from Jira and vise versa.

Answer 3

A Release is of a Product that is used by Users. If the Components in your Release are individually releasable, consider multiple releases. Otherwise, it's a release of a single product with details of a number of changes.

Releases have costs associated; release too frequently and your users will disengage as they get overwhelmed with all the noise about releases. Not releasing frequently enough will risk disengagement due to perceived lack of progress.

A Product Owner should have usage metrics and/or hypotheses that can gauge user engagement over time; releases will show deltas in user engagement - increases overall, shifts from older features to new features or reduced overall.

Work with the Product Owner to determine the right cadence for release.

Once you've got an understanding of the frequency and type of releases, it'll be clear what to call them. In the mean time, Product-Major-Minor is sufficient.