What's the difference between version and release

Jim Constant December 4, 2014

I feel like this is something that should be obvious but it's not (to me at least). I've searched and couldn't find a clear answer so can someone please explain the difference?

Thanks

4 answers

1 accepted

9 votes
Answer accepted
luke_majewski December 4, 2014

In JIRA, versions are intended to indicate an actual version of your software (2.3.5).  However, depending on how your software is being delivered, you could also use releases in this field.  For instance, our project has time-boxed releases where the content of the release is flexible but the release date is not.  Therefore, version and release are somewhat interchangeable.  However, I could see an instance where you separately track software versions and still have a separate concept called a release.

For example, you could have your versions go along as 2.3.5, 2.3.6, 2.4.0, 2.4.1, etc. and not necessarily know what version will go into your release 1, 2, 3, etc.  In this case, you could have version 2.4.1 deployed as part of release 2.  This is especially true if you have multiple software projects all going into a single release.

 

Matt Sweetnam April 6, 2021

Excellent response. We use releases for Sprint Demos and the like, which are quite different from software versions - though jira doesn't really enforce any structure.. 

6 votes
Rahul Aich [Nagra]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 4, 2014

IN context of jira, a version is a milestone. You tag several issues with a version say 1.1 and when say you deliver that version to a customer you go and mark the version as released.

All unresolved issues in that version then can be moved into the next release say 1.2.

Does that answer your question?

Rahul

4 votes
Michael Collins August 15, 2018

We use fix version to define a release, i.e. Version 2.1.  We use Affects Version to define bugs and issues that emerge post-release so that we know which release a bug affects. This helps us understand if an issue is still a problem or if an issue may be superseded by a release in flight.

We do this because this helps us keep our bug resolutions organized and targeted, as we often have multiple releases in progress across a variety of environments and this helps facilitate QA.

This has a tremendous amount of power when you have to support a central group who support groups of customers/end users that uptake or upgrade software at varying rates. 

For example:

  • Dev environment: Team is working on Fix Version 2.3 in Development
  • Staging environment: Team is testing Fix Version 2.2 in QA
  • Releases in Production: Fix Version 2.1 in use with customers A, B, & C.  Version 2.0 is in use with customers X, Y, & Z

If a user finds a bug in their production software, the Affects Version would be tagged w/ Version 2.0 or Version 2.1, depending on which version they have in use.

If a tester finds a bug in Staging, the Affects Version would be tagged with 2.2.

And so on...

Heather Reid February 7, 2020

Thank you Mr. Collins,

This example was very helpful. My brain was having a very hard time wrapping around the concept.

Heather

Frederick Fernandes February 17, 2020

so till a Version has not reached Production (i.e. a Version´s status is not updated to Released) it does not  convert into a Release.

 

If a bug affects  Release, use Jira´s "Affects Release" field to update the Release (status is now Released) and to the current/relevant Version number (whose status is Unreleased).

 

Hmmm... well that´s pretty straight forward........... I wonder if we should use the Description field to make it more obvious.... i.e. if Version is in QA and we are moving to Pre-Prod, we update the description field to say something like "Was in QA" to "Version released to Pre Prod", for additional context....... i hope the release burn down charts do not get messed up if we use this approach.

Like # people like this
1 vote
Jim Constant December 4, 2014

@Rahul Aich [Nagra] - it helps, Rahul. Thank you. If I think of it the way you describe then it seems the version and the release end up being essentially the same thing. When you release version 1.1 then that release is simply all of the completed issues that are tagged version 1.1.

@Luke Majewski - thank you too and I think you make a key point. It sounds like how you deliver software makes the difference. In my org, we work on a release until it's done, then release it, then start the next one. Because of this, I think version and release can be thought of interchangeably. 

Does this sound right?

hitesh kumar dewangan July 30, 2018

does that mean that your release of the product will be bug-free, and will not have any improvement?

 

So in your case, affect version and fixed version will always be same right?

 

"

Affects version is the version in which a bug or problem was found. Although it can be useful for tracking problems, it isn't used very often in Jira. 

 

Fix version is the version where you plan on releasing a feature or bugfix to customers. This field is used for release planning, monitoring progress and velocity, and is used widely in reporting. This is most likely the field you want. 

Vernon Fowler October 5, 2018

The comments here about versions are spot on.

JIRA mostly uses the term release in the verb sense. That is to say:

  1. Before it's ready, a version is unreleased.
  2. You release a version.
  3. Then that version was released.

The interface below from a recent version of JIRA has confused us with the use of Releases in the heading.

JIRA versions and releasing.png

It's ambiguous when release is used in the noun form. Another point of confusion is Release notes - if you use release as a verb, this should be Version notes.

We make an annotation in analytics when a version is released - hence the release date is critical. Any changes in patterns / trends after a version is released can be easier to understand when we look at the notes associated with that version.

Like # people like this
Mark Knoop February 27, 2020

So a situation we have is that several versions might be created before one is released. So having a separate (noun) concept of release is useful. The problem I have is that all the issues that get fixed in various versions (between the two that got released) need to also be associated with that release ideally. Is this possible? Or is it better to have a separate release project for this purpose?

Frederick Fernandes February 27, 2020

@Mark Knoop  yes you can use "affects version" to update an issues version number, where you can enter the previous released version´s number and the current planned versions number (which is in unreleased state).

Like Zoltan Vida likes this

Suggest an answer

Log in or Sign up to answer