JIRA Versions and Releases
Software reaches users in packages with names like 1.0, 1.1, and 2.0. JIRA tracks these packages through versions. A version collects every issue that belongs to one delivery, and a release marks the moment that delivery goes live.
Layman's View: Editions of a Book
A publisher prints a first edition, followed by a second edition with corrections and new chapters. Readers know exactly which edition they hold. A JIRA version plays the same role for a product. Users, testers, and support staff all refer to the same labelled package.
What a Version Contains
Version Details
| Detail | Purpose | Example |
|---|---|---|
| Name | Identifies the package | 2.1.0 |
| Start Date | Marks when work begins | 1 March |
| Release Date | Marks the planned delivery | 30 April |
| Description | Explains the theme | Faster search and bug fixes |
Affects Version and Fix Version
Two fields connect issues to versions. Affects Version records where someone found a problem. Fix Version records where the correction ships.
Version 1.0 -------------> Version 1.1 -------------> Version 1.2
| | |
Bug found here Fix ships here New feature ships here
(Affects Version) (Fix Version) (Fix Version)
A bug reported in 1.0 and repaired in 1.1 carries both labels. Support teams read the labels to tell customers which update solves their problem.
Creating a Version
- Open the project and go to the Releases or Versions page.
- Click the option to create a version.
- Type a name and pick start and release dates.
- Add a short description.
- Save the version.
- Open each issue and set its Fix Version field.
Version Lifecycle
Every version travels through three stages.
[ Unreleased ] ------> [ Released ] ------> [ Archived ] work in progress shipped to users hidden from menus
Archiving a version removes it from everyday drop-down lists. The data stays safe and searchable.
The Release Page
A release page lists every issue in a version and groups them by status. A team reads the page to judge readiness. Unfinished issues stand out immediately.
Clicking Release triggers a check. JIRA asks what to do with open issues. The team moves them to a later version or ignores them. That prompt prevents unfinished work from shipping by accident.
Release Notes
JIRA builds release notes from the Fix Version field. The notes list new features, improvements, and bug fixes in one tidy summary. Teams share the summary with customers, testers, and support agents.
Sprints and Releases Compared
Sprints and releases solve different problems. A sprint is a fixed time box for planning work. A release is a delivery to users. One release can hold the output of many sprints.
Sprint 1 ---+
|
Sprint 2 ---+---> Release 1.0
|
Sprint 3 ---+
Sprint vs Release
| Point | Sprint | Release |
|---|---|---|
| Purpose | Organize team work | Deliver value to users |
| Length | Fixed, often two weeks | Flexible |
| Owner | Scrum team | Product and release managers |
| Field used | Sprint | Fix Version |
Best Practices
- Use a clear naming pattern, such as major.minor.patch.
- Set Fix Version during planning, and avoid leaving it for the final day.
- Review the release page two days before launch to catch open issues.
- Archive old versions each quarter to keep menus short.
Real-World Example
A travel app team plans version 3.2 with a new booking screen and ten bug fixes. Developers tag every related issue with Fix Version 3.2. The release manager opens the release page on Thursday and spots two open bugs. The team fixes one and moves the other to version 3.3. Friday's release goes out with an accurate list of changes.
Summary
Versions label each delivery of a product. Fix Version and Affects Version tell the story of every bug and feature. The release page shows readiness, and release notes inform customers. Sprints organize work, and releases deliver it.