What is a Jira Version?

Versions and release dashboards

The Releases page (formerly Versions page) lists every version in the project with its name, status, start date, release date, and issue counts. The page shows:

• Issues in this version - everything with fixVersion = "X".
• Progress bar - the share of those issues that are in Done status.
• Unresolved issues - the rest.

This is the standard release-readiness view: a glance tells the release manager what’s left to close.

Releasing a version

Marking a version as Released in Jira does three things:

1. Changes the version’s status to Released.
2. Records the release date (or accepts the date supplied).
3. Optionally prompts to move unresolved issues into another version (so the open work doesn’t silently stay tagged against the released version).

Most teams pair the release action with their build pipeline - the same commit that triggers a production deploy can hit Jira’s REST API to mark the version released.

Fix Version vs. Affects Version semantics

The two fields look similar but mean different things:

• Affects Version/s - which released versions are affected by this bug? Filled by reporters when filing defects.
• Fix Version/s - which upcoming versions will resolve this issue? Filled by triagers during planning.

A common pattern: when a regression is found, the reporter sets Affects Version to the version they observed the bug in; triage sets Fix Version to the next planned release. Both fields can hold multiple versions - useful when a bug is fixed in two parallel maintenance branches.

Versions and the release notes problem

fixVersion = "4.12.0" AND status = Done is the JQL for “what shipped in 4.12.0?” - the basis for generated release notes. Many teams pair this query with a custom field (often called “Release Note Text” or similar) to capture the customer-facing description on each issue, then concatenate those into a public changelog at release time.

Version archival

Long-lived projects accumulate hundreds of released versions over time, slowing the Releases page and the version picker on screens. Archiving old versions (keep them released, but mark archived) hides them from default views while preserving the history. Archived versions can still be queried via JQL.

Cross-project version coordination

When several projects need to ship together (a coordinated release across services), each project still has its own version object. Tools to coordinate them:

• Advanced Roadmaps / Plans cross-project releases - one cross-project release object linked to per-project versions.
• Naming convention - every project uses the same version name string. Cheap but easy to drift.
• REST API automation - a script creates and releases matching versions across projects from a single trigger.

Common questions

Related glossary terms

• Component - A component in Jira is a project-level tag that groups issues by the part of the product they affect - e.g., 'checkout-service', 'mobile-app', 'billing-api'.
• Sprint - A Jira sprint is a fixed-length iteration - usually 1 to 4 weeks - during which a Scrum team completes a committed set of issues from the backlog.