4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving

Versions, Fix Versions, Release Lifecycles & Project Archiving

Software development and enterprise delivery lifecycles require strict tracking of when capabilities are deployed and when defects are discovered. In Jira Cloud, Versions provide the temporal backbone for release management, roadmap forecasting, changelog generation, and software auditability. Furthermore, as organizations mature and initiatives conclude, administrators must execute defensible Project Archiving strategies to maintain instance hygiene, optimize search performance, and safeguard historical compliance data.

---

Architecture of Versions in Jira Cloud

A Version is a project-scoped temporal milestone managed via Project settings > Versions or the Releases tab in the project navigation sidebar. Like Components, Versions belong to a single project container natively, allowing teams to maintain distinct release cadences (e.g., v1.0.0, v1.1.0, 2026-Q3-Hotfix).

Core System Version Fields

Jira provides two primary system fields to track versions on issues:

1. Fix Version/s: Represents the version in which an issue is scheduled to be delivered or was actually released. This is the operational engine of the Jira Release Hub, burndown charts, and release reports. An issue can be tagged with multiple Fix Versions if it represents work backported across maintenance branches.
2. Affects Version/s: Represents the historical software version in which a bug, defect, or vulnerability was observed or introduced. Primarily utilized on Bug and Defect issue types to track quality regression across legacy releases.

Version Metadata Attributes

When establishing a version, administrators can specify:

• Version Name: Mandatory text identifier (must be unique within the project).
• Description: Scope summary or changelog summary.
• Start Date: The planned beginning of development for the milestone.
• Release Date: The target or actual deployment date. This date drives the Overdue flag if reached before release.

The Four Version Lifecycle States

Versions transition through four operational states that govern their visibility across issue screens, agile backlogs, and user pickers.

                          VERSION LIFECYCLE STATE MACHINE

                   ┌───────────────────────────────┐
                   │          Unreleased           │ ◀── Default state on creation
                   │ (Active, Selectable in Picker)│
                   └──────────────┬────────────────┘
                                  │
                 ┌────────────────┴────────────────┐
                 ▼                                 ▼
  ┌───────────────────────────────┐ ┌───────────────────────────────┐
  │            Overdue            │ │           Released            │
  │(Target date past; Unreleased) │ │ (Completed milestone, locked) │
  └──────────────┬────────────────┘ └──────────────┬────────────────┘
                 │                                 │
                 └────────────────┬────────────────┘
                                  ▼
                   ┌───────────────────────────────┐
                   │           Archived            │
                   │(Hidden from pickers, read-only│
                   │ JQL searchable, audits kept)  │
                   └───────────────────────────────┘

1. Unreleased (Active)

• The default state upon version creation.
• Appears in the Fix Version and Affects Version pickers across Create, Edit, and Transition screens.
• Fully visible on the Scrum Backlog and Kanban planning panels for issue scheduling.

2. Released

• Represents a concluded release milestone.
• Transitioned by selecting Release from the Releases management hub.
• Picker Behavior: In issue version pickers, released versions are grouped under a distinct Released Versions section. While they can still be selected for historical attribution, they are visually demoted below active unreleased versions.
• Forms the basis for historical release reports, release notes, and delivery cycle time analysis.

3. Archived

• Represents a retired or deprecated milestone preserved strictly for historical auditability.
• Transitioned by selecting Archive from the version action menu.
• Critical Picker Behavior: Archived versions are completely removed and hidden from the Fix Version and Affects Version pickers. Users cannot select an archived version when creating or editing an issue.
• Historical Preservation: Issues that were tagged with the version prior to archiving retain the version value intact. The value is not erased.
• JQL Queryability: Archived versions remain fully queryable via JQL:

  /* Retrieve all defects fixed in legacy archived release v1.0 */
  project = 'CORE' AND fixVersion = 'v1.0' AND issuetype = Bug
  

4. Overdue (System Status Flag)

• An automated visual indicator displayed in red on the Releases page.
• Triggered whenever an unreleased version's Release Date is earlier than today's current calendar date.
• Does not alter picker behavior or restrict issue transitions; it functions purely as an operational warning to project managers.

Releasing a Version: Managing Unresolved Issues

When a release coordinator or project administrator clicks Release on an unreleased version via Releases > ... > Release, Jira Cloud evaluates the resolution status of all issues associated with that version.

The Unresolved Issues Dialog

If the version still contains unresolved issues, Jira intercepts the action with a decision dialog:

                     RELEASE VERSION: UNRESOLVED ISSUES DIALOG

   ┌────────────────────────────────────────────────────────────────────────┐
   │ Release Version: Release 2.4                                           │
   │                                                                        │
   │ There are 6 unresolved issues currently assigned to this version.       │
   │ What do you want to do with these issues?                              │
   │                                                                        │
   │  (o) Move unresolved issues to version: [ Release 2.5 (Unreleased) ▼ ] │
   │                                                                        │
   │  ( ) Ignore unresolved issues and keep them in this release            │
   │                                                                        │
   │                                        [ Cancel ]  [ Release Version ] │
   └────────────────────────────────────────────────────────────────────────┘

Administrators must select one of two actions:

1. Move Unresolved Issues to Another Version: Jira automatically strips the current version from all open issues and re-tags them with a selected upcoming unreleased version (e.g., Release 2.5). This is the standard agile best practice, ensuring that incomplete scope rolls forward into the subsequent release backlog.
2. Ignore Unresolved Issues: Jira releases the version while leaving all unresolved issues assigned to it. This pattern is utilized when documenting scope that was planned for a release but ultimately abandoned or deferred without immediate rescheduling.

---

Merging, Deleting, and Naming Versions

Blueprint 2.3 also tests the other version actions. Users need Administer Projects or the more specific Manage versions (releases) permission to perform them.

Naming rule: version names must be unique within a project. Two different projects can each have a version called 2.0, because versions belong to one project.

Merge vs. archive vs. delete: Only archive keeps the version itself. Merge keeps the issue associations by moving them to another version. Delete gives you the choice to move or remove them, so pick carefully if reports depend on the version.

---

Project Archiving: Cloud Premium/Enterprise Native vs. Standard Workarounds

As organizations evolve, hundreds of Jira projects eventually conclude. Inactive projects clutter global search pickers, degrade navigation, confuse users during issue creation, and increase administrative cognitive overhead.

Native Project Archiving (Jira Cloud Premium & Enterprise)

In Jira Cloud Premium and Enterprise plans, project archiving is a native action (Settings > Projects (Spaces) > Manage, then Move to archive, or from the project's Details page). Projects archived on Premium can still be viewed and restored if the site later moves to Standard.

• Read-Only Lock: The archived project becomes completely read-only. No user (including Jira Administrators) can edit issues, add comments, log work, or execute transitions without unarchiving the project first.
• Search Containment: Issues in archived projects don't appear in basic or advanced search results. They can still be opened by direct link, but they can't be edited.
• Who can archive: A Jira admin archives company-managed projects. Team-managed projects can be archived by a Jira admin or the project admin.
• Seamless Restoration: A Jira admin can restore an archived project from the Archive list, which brings back its issues, boards, and configuration so work can continue.
• Backups: If a site backup is created after a project is archived, the project is still archived after that backup is restored (it appears in the Archive list).

Project Archiving Workaround (Jira Cloud Free & Standard)

Because Jira Cloud Free and Standard tiers lack native archiving, administrators must construct an Archived Project Scheme Workaround:

1. Create an Archive Permission Scheme: Establish a dedicated permission scheme (e.g., 'Corporate Inactive / Read-Only Scheme'). Remove all users, groups, and roles from every permission (including Create Issues, Edit Issues, Assign Issues, Transition Issues), retaining only Browse Projects granted exclusively to Jira Administrators and compliance auditors.
2. Associate the Inactive Project: Link the target project to this read-only permission scheme.
3. Rename Project Name and Key: Prepend the project name with [ARCHIVED] (e.g., [ARCHIVED] Legacy Billing Migration) and optionally assign it to an Archived Projects Project Category to facilitate filtering.
4. Shortcomings: Issues in Standard edition projects still occupy search indexing resources and will appear in basic search queries for any user holding Browse Projects permissions.