Study guide
4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving
Key Takeaways Explain This Topic AI
Versions represent milestones, sprints, or release deployments, tracked primarily through two system fields: Fix Version/s (target/actual delivery) and Affects Version/s (defect discovery).
The version lifecycle progresses through distinct states: Unreleased (active development), Released (completed milestone), Archived (historical audit, hidden from pickers), and Overdue (past target date).
When releasing a version containing unresolved issues, Jira prompts the administrator to either move unresolved issues to an upcoming unreleased version or ignore them and keep them in the released version.
Archiving a version hides it from the Fix Version and Affects Version pickers during issue creation and editing, while preserving historical values on existing issues and retaining JQL queryability.
Versions can be merged (associations move to the target version), deleted (you choose whether to move or remove references), or archived (hidden from pickers but kept in history), and version names must be unique within a project.
Last updated: September 2026
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:
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.
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:
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.
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.
Action What Jira Does When to Use It
Merge You pick one or more versions to merge into a target version. Issues with the merged versions in Fix Version/s or Affects Version/s now show the target version, and the merged versions are removed. Two versions were created for the same release, or a planned release was folded into another
Delete Jira asks what to do with issues that reference the version: move their Fix Version/s and Affects Version/s values to another version, or remove the values. A version was created by mistake and should vanish from history
Archive Hides the version from pickers but keeps values on issues and in JQL A release is old but its history matters
Release Marks the version released and handles unresolved issues as described above The release actually shipped
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.
Archiving Dimension Cloud Premium / Enterprise Native Archiving Cloud Standard Workaround
Mechanism Built-in native archiving feature ( Projects > ... > Archive ) Administrative scheme modifications and naming conventions
Issue Searchability Excluded from search results; still reachable by direct link (read-only) Still returned in global JQL unless explicitly excluded by query
Project Navigation Hidden completely from project menus, sidebars, and pickers Visible in project menus unless hidden via permission schemes
Data Modification Fully read-only; no issues can be created, edited, or transitioned Read-only only if permission schemes are painstakingly stripped
Restoration A Jira admin restores it from the Archive list in project (space) settings Manual scheme re-association and name reverting
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 :
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.
Associate the Inactive Project : Link the target project to this read-only permission scheme.
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.
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.