How to Create a Release in Jira: Full Step-by-Step Guide

Creating a release in Jira sounds simple until your team cannot find the version, issues stay unassigned, or the release page shows confusing progress. A poorly configured release can make a finished sprint look incomplete and leave stakeholders asking what is actually ready.

That confusion grows when teams mix up versions, sprints, and deployment milestones. You may also see different menus depending on whether your project is company-managed or team-managed.

But here's the truth: creating a Jira release usually takes only a few minutes when you know where to look. You need the right project permissions, a clear version name, and a realistic target date.

This guide walks you through the complete process, explains what each release field means, and shows how to track work after creating the release.

How to Create a Release in Jira

To create a release in Jira, open your project, go to the Releases or Versions page, create a new version, add a name and optional dates, then assign issues to that version. The exact menu label depends on your Jira project type and interface.

Step 1: Open the Correct Jira Project

Sign in to Jira and open the project connected to the work you want to ship. A release belongs to one project, so choosing the wrong project can hide the version from your team.

For example, a mobile app team may manage Android and iOS work in separate projects. Creating version 4.2.0 in the Android project will not automatically make it available in the iOS project.

Check the project name and key before continuing. This small check prevents issues from being assigned to the wrong release.

Step 2: Open Releases or Versions

From the project sidebar, look for Releases, Versions, or a similar option. Jira may place this link under the project menu, depending on your permissions and project configuration.

In some Jira layouts, you can open the page by selecting Project settings and then choosing Versions. In others, the Releases page appears directly in the project navigation.

You might be wondering: why are the names different? Jira uses “version” as the technical object, while the interface often presents it as a release. Both usually refer to the same milestone.

Step 3: Create the Version

Find the control labeled Create version, Add version, or Create release. Select it to open the release details form.

Enter a clear version name. Good examples include:

• 2.4.0 for semantic versioning
• Mobile App - March 2026 for a calendar-based release
• Q2 Customer Portal for a business milestone
• API v3 for a major interface change

Avoid names such as Next, Final, or New Release. These names become difficult to understand after several months.

Step 4: Add Start and Release Dates

Add a start date if your team wants to show when release work began. Add a release date when you have a planned launch or completion target.

Dates help Jira display timeline information and release progress. They also give your team a shared point of reference during planning meetings.

Use an estimated date when the schedule is still flexible. You can update it later after reviewing scope, testing progress, or deployment readiness.

Step 5: Add a Description

Use the description to explain what the release includes. A short description is enough, but it should answer the main question: what is this version meant to deliver?

For example:

Introduces saved searches, improves dashboard loading speed, and adds administrator audit controls.

You can also mention important exclusions, testing expectations, or rollout notes. Keep the description focused because team members may scan it during a planning call.

Step 6: Save the Release

Select Create, Save, or the equivalent confirmation button. Jira should add the new version to the project’s release list.

Review the version name and date immediately after saving. If you notice a mistake, open the version actions menu and edit the details before assigning work.

Step 7: Assign Issues to the Release

Creating a version does not automatically place work inside it. You must assign relevant issues using the Fix Version/s field.

Open an issue, find Fix Version/s, and select the new release. You can also update several issues together through Jira’s bulk-edit feature when your permissions allow it.

For example, a password-reset feature may include a story, two bugs, and a testing task. Assigning all four issues to the same version gives Jira a more accurate view of release progress.

Step 8: Review the Release Progress

Return to the Releases page and inspect the issue breakdown. Jira commonly groups work by status, such as to do, in progress, and complete.

Look for unresolved issues, missing owners, and items that are larger than expected. A release with ten completed issues and three unresolved bugs may need a scope decision before launch.

Here's why: the release page is useful only when the Fix Version/s field is maintained consistently. Unassigned work will not appear in the release view, even when that work is essential to launch.

Step 9: Mark the Release as Released

When the planned work is complete and your team has approved the launch, open the version actions menu and choose Release or Mark as released.

Jira may ask you to confirm the release date. Use the actual launch date if your team tracks historical delivery performance.

Do not mark a version as released simply because a sprint ended. A sprint is a time-boxed work period, while a release represents a deliverable milestone. They may finish together, but they do not have to.

What Jira Releases, Versions, and Sprints Mean

Jira uses several planning concepts that can look similar. Understanding the difference helps you choose the right field and avoid misleading progress reports.

Jira concept	What it represents	Typical use
Version or release	A deliverable milestone	Grouping work planned for a product launch
Sprint	A fixed period for completing selected work	Planning two weeks of team activity
Epic	A large body of related work	Tracking a major product initiative
Fix Version/s	The release connected to an issue	Showing which version should contain the work

Consider a customer portal redesign. The initiative may be an epic, the work may span four sprints, and the finished capability may ship in version 5.0.

The release is therefore the delivery milestone, not the entire planning hierarchy.

Company-Managed and Team-Managed Project Differences

Jira’s release workflow can vary by project type. The basic idea remains the same, but navigation and permission behavior may differ.

Company-Managed Projects

Company-managed projects usually offer centralized configuration. Project administrators often manage versions through project settings or the Releases page.

These projects may use shared workflows, screens, and permission schemes. As a result, the Fix Version/s field can appear consistently across several teams.

A platform team might use a company-managed project when multiple squads contribute to the same product. That structure makes shared release naming easier.

Team-Managed Projects

Team-managed projects give individual teams more control over configuration. You may find releases directly in the project sidebar, with fewer organization-wide settings.

Team-managed projects can be convenient for a small product team. However, different teams may create similar version names without a shared naming policy.

For example, two projects could each contain a version called 1.0. Jira treats those as separate versions because they belong to different projects.

How to Identify Your Project Type

Open the project settings area and look for indicators such as Details, Project type, or configuration options. Jira may also show the project type near the project name.

If you cannot find Releases or Versions, ask a project administrator to confirm the project type and your permissions. Changing menus repeatedly will not solve a permission problem.

How to Plan a Release Before You Create It

A release works best when you define its purpose before opening Jira. You do not need a long planning meeting, but you do need a few clear decisions.

Choose a Naming Convention

Select one naming pattern and apply it consistently. Semantic versioning works well for software products, while month-based names may suit marketing or operational launches.

For example, a team could use:

• Major releases: 3.0.0
• Minor feature releases: 3.1.0
• Patch releases: 3.1.1

Another team may choose 2026-03 Web Release. Either approach can work when everyone understands the pattern.

Define What “Ready” Means

Agree on the conditions that make a release ready. Your checklist might include completed development, passed testing, approved changes, updated customer guidance, and a deployment plan.

Without a shared definition, one person may consider a release complete when coding ends, while another waits for production verification.

The best part? Writing these conditions down in the release description gives the team a quick reference during final review.

Estimate Scope Carefully

Review the issues before assigning them to a version. Include essential bugs and operational tasks, not only visible product features.

Imagine a checkout release with six feature stories but no monitoring task or rollback work. The feature scope may look complete, while operational readiness remains unfinished.

Use the release view to expose that gap early.

How to Track and Manage a Jira Release

Creating a version is only the beginning. The release page becomes valuable when your team keeps issue statuses, estimates, and ownership current.

Monitor Unresolved Work

Check unresolved issues regularly. A single high-priority defect can matter more than several completed low-risk tasks.

Sort or review work by priority, status, and assignee. This helps you identify whether the remaining work is a genuine blocker or a candidate for a later release.

Move Issues Between Releases

If an issue will not ship, edit its Fix Version/s field and move it to a later version. Add a short reason in a comment when the change affects stakeholders.

For example, you might move a reporting enhancement from 4.2 to 4.3 because the underlying permissions work needs more testing.

Moving the issue keeps the current release view honest.

Use Release Progress During Meetings

Open the Releases page during stand-ups, planning sessions, and launch reviews. Discuss the remaining work instead of relying on memory.

A release showing three unresolved bugs and one unassigned task gives your team a concrete conversation starter. You can decide who owns each item and whether the target date remains realistic.

Archive Old Versions Carefully

After a release has been completed for a reasonable period, consider archiving it if your Jira configuration supports that action. Archiving reduces clutter while preserving a cleaner planning experience.

Do not archive a version while teams still need to search, report, or audit its issues. Confirm that historical reporting remains available for your organization.

ONES as a Release Planning Option

Jira can handle release tracking effectively, but some teams want a broader workspace for product planning, execution, and delivery coordination. ONES is one option to evaluate when your workflow extends beyond issue tracking.

ONES can support release-oriented planning through capabilities such as:

• Product roadmaps that connect strategic goals with delivery milestones
• Backlog organization for prioritizing upcoming work
• Custom workflows for development, review, testing, and approval
• Milestone tracking for release dates and major delivery checkpoints
• Dashboards that summarize progress across teams
• Dependency visibility for work that spans multiple groups
• Permission controls for different project roles
• Reports that help teams review delivery trends

For example, a product group could connect a customer request to an initiative, link that initiative to planned work, and monitor its progress toward a milestone.

The right choice depends on your operating model. Jira may fit a team already invested in Atlassian workflows, while another organization may prefer a broader product planning environment.

Common Mistakes When Creating a Jira Release

Creating the Version in the Wrong Project

Problem: The release exists, but your issues cannot use it.

Solution: Confirm the project key before creating the version. If several projects represent one product, decide whether each project needs its own release or whether a shared planning approach is more suitable.

Using Unclear Version Names

Problem: Names such as Final and Next become confusing when plans change.

Solution: Use a consistent convention with a number, date, product area, or combination. Make the name understandable without extra explanation.

Forgetting to Assign Issues

Problem: The release appears empty or more complete than it really is.

Solution: Add the new version to every issue that belongs in the release. Review the project backlog and search results for related work that may have been missed.

Confusing Sprints with Releases

Problem: The team marks a release complete whenever a sprint ends.

Solution: Treat the sprint as a planning period and the release as a delivery milestone. Link them when useful, but manage them separately.

Marking a Release Too Early

Problem: Jira shows the version as released while critical work remains unresolved.

Solution: Define readiness criteria before launch. Confirm testing, approvals, deployment, and essential operational tasks before changing the version status.

FAQs

What is the difference between a Jira version and a release?

In most Jira interfaces, a version is the technical object used to group issues for a planned delivery. The Releases page presents that version as a release milestone. Teams often use the terms interchangeably. The important field is Fix Version/s, which connects an issue to the planned delivery. A sprint describes when the team works, while a version describes what the team intends to deliver.

Why can’t I see the Releases option in Jira?

You may be viewing a different project type, using a customized sidebar, or lacking the required project permission. Open project settings and check whether Versions appears there. If it does not, ask a project administrator to review your access. Also confirm that you opened the intended project. Jira does not show versions from one project inside another project automatically.

Can I create a Jira release without assigning issues?

Yes. You can create a version with a name, dates, and description before assigning any issues. However, an empty release cannot show meaningful progress. After creating it, review the backlog and connect the relevant stories, bugs, tasks, and technical work through the Fix Version/s field. Assigning work early gives your team a clearer view of scope and delivery risk.

Can one Jira issue belong to more than one release?

Yes, Jira can allow multiple values in the Fix Version/s field. Use this carefully. Multiple versions may make sense when an issue spans releases or represents a shared technical change. In many cases, assigning one target release creates clearer reporting. If the issue will ship in separate stages, consider splitting it into smaller issues so each delivery has a precise scope.

How do I change a Jira release date?

Open the Releases or Versions page, find the relevant version, and choose its edit option. Update the start date, release date, or description, then save the change. Share significant date changes with stakeholders because reports and planning discussions may rely on that target. If the date moved because of scope changes, record the reason in an appropriate project comment or planning note.

Should I mark a release as released when the sprint ends?

Only when the planned release work is ready for delivery. A sprint can end with unfinished work, while a release may include work from several sprints. Review unresolved issues, testing results, approvals, deployment readiness, and operational checks first. If essential work remains, keep the version unreleased or move that work to a later version. This keeps Jira’s delivery history accurate.

Conclusion

Creating a release in Jira is straightforward: open the right project, create a version, add useful details, assign issues, review progress, and mark it released only when the work is ready.

The real value comes from the habits around the release. Use consistent names, separate sprints from delivery milestones, maintain the Fix Version/s field, and review unresolved work often.

But here's the truth: a release page cannot fix unclear scope or missing ownership by itself. It can reveal those problems early, giving you time to make a better decision.

When your team uses Jira versions as living delivery checkpoints, planning becomes easier to understand and launch conversations become far more concrete.