New Features Policy

This policy doesn't apply to bugs. Check our Data Center Bug Fix Policy or Cloud Bug Fix Policy to learn about our approach to bug fixing.

How we choose what to implement

There are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritize and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.

How to track when features are implemented

Cloud products

We're continuously improving and updating our Cloud products. To see the latest changes, take a look at the Atlassian Cloud release notes blog.

Data Center products

When a new feature or improvement is scheduled, we'll update the fix version on the relevant Jira issue to indicate the earliest product version that will include the change. This update often happens close to the product release date.

For a summary of changes, see the release notes for your product:

Product roadmaps

We publish a public roadmap for Jira Cloud products, Confluence Cloud, Bitbucket Cloud, and our Cloud Platform. This lets you know what’s coming soon and what we’re thinking about for future updates.

The Atlassian Cloud release notes blog and Bitbucket Cloud blog may also contain information on upcoming changes.

We don’t provide specific release dates for upcoming changes.

Feature and improvement suggestions

Feedback from customers like you helps us shape and improve Atlassian products for all teams. We’re continuously learning, analyzing and interviewing customers to make our products more intuitive and user-friendly, and to meet feature requirements. We encourage you to share your feedback and how you’re using Atlassian products through Atlassian Community, jira.atlassian.com, or directly within our Cloud products. Learn more about our plans and the latest changes via our Cloud Roadmap or Data Center Roadmap.

We get a large number of suggestions and feature requests. Your comments and votes on suggestions help us understand what you’re passionate about and how you want our products to support you and your team. The most helpful information you can provide us when commenting on issues is how a particular suggestion would help you. If you describe your use-case to us, and how the suggested change would benefit you and your team, it lets us gain a much deeper understanding of the need behind the suggestion.

Suggestions often have an impact on what we work on, even if we ultimately choose not to implement a suggestion exactly as it’s described. Our ultimate goal is to understand what you and all of our customers need and to create products that meet those needs. Occasionally, that’ll mean implementing a suggestion as described, but it usually means working to understand the need behind the suggestion and how we can meet that need for as many users as possible.

While we endeavor to update and respond to popular suggestions, the volume we receive means there will often be occasions when we can’t provide an update or response. We don’t provide any compensation or credit for feature suggestions that we implement.

Join the conversation on Atlassian Community

Our Product Managers regularly post articles about new features and changes to the Atlassian Community. You can comment on these posts, ask questions, and discuss with our PMs and other Atlassian users.

Release terminology for Data Center products

Platform release (example: 4.0) contains significant or breaking changes. For example changes or removal of existing APIs, significant changes to the user experience, or removal or a major feature.
Feature release (example: 4.6) can contain new features, changes to existing features, changes to supported platforms (such as databases, operating systems, Git versions), or removal of features. These were previously referred to as 'major' releases by most products.
Bugfix release (example: 4.6.2) can contain bug fixes and stability and performance improvements. Depending on the nature of the fixes they may introduce minor changes to existing features, but do not include new features or high-risk changes, so can be adopted quickly. We recommend regularly upgrading to the latest bugfix release for your current version. These were previously referred to as 'maintenance' releases by most products.

In addition to the three main release types, a feature release can also be designated a Long Term Support release (formerly known as an Enterprise release), which means it will receive bug fixes for a longer period of time than a standard feature release.

Long Term Support releases

Long Term Support releases (formerly known as Enterprise releases) are for Data Center customers who prefer to allow more time to prepare for upgrades to new feature versions but still need to receive critical bug fixes. If you only upgrade to a new feature version about once a year, a Long Term Support release may be a good fit for your organization. For Jira Software, Confluence, Bitbucket, and Bamboo we will:

Designate a feature release as a Long Term Support release, at least every 12 months.
Backport critical security fixes, as outlined in our current security bug fix policy, and fixes relating to stability, data integrity, or critical performance issues.
Make bug fix releases available for the designated version until it reaches end-of-life.
Provide a change log of all changes between one Long Term Support release and the next to make upgrading easier.

Not all bug fixes will be backported. We'll target the bugs and regressions that we deem most critical, focusing on stability, data integrity, or performance issues. There may also be some fixes that we choose not to backport due to risk, complexity, or because the fix requires changes to an API, code used by third-party apps (also known as add-ons), or infrastructure that we would usually reserve for a platform release.

For Jira Software Data Center customers, we'll endeavor to allow zero downtime upgrades between one Long Term Support release and the next Long Term Support release, but can't guarantee that downtime will not be required, depending on the nature of the changes. The change log will indicate if a zero downtime upgrade will be available.

In the example below, version 4.2 has been designated a Long Term Support release. The number of bug fix releases and timing illustrated below is just an example, your product's release cadence may differ.

Page tree