Implementation of New Features Policy
We don’t publish roadmaps with specific release dates.
- Suggested features and improvements are tracked in our public issue tracking system https://jira.atlassian.com/. We encourage and display comments from customers.
- Our product managers review the most popular issues on a regular basis.
- New features are selected and scheduled based on a number of factors, not just popularity.
- We provide regular updates on the top issues.
How to track when features are implemented
We're continuously improving and updating our Cloud products. To see the latest changes, take a look at the Atlassian Cloud release notes blog.
Server and 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. While we have roadmaps for future releases, we don't make these public.
For a summary of changes, see the release notes for your product:
- Jira Software | Jira Service Desk | Jira platform | Advanced Roadmaps for Jira
- Confluence | Questions for Confluence | Team Calendars for Confluence
- Bitbucket | Bamboo | Fisheye | Crucible
How we choose what to implement
When we plan a release, we use many factors to help decide which suggestions to implement, including:
- Customer feedback - there are many ways we listen for your feedback:
- formal customer interviews and other research activities
- events like Atlassian Summit, developer conferences, and road shows
- in-product feedback from evaluation and EAP (early access program) releases
- comments and votes on issues in https://jira.atlassian.com/, our public issue tracker
- questions and posts on Atlassian Community.
- Support team insights - our support team know which issues are the most challenging, and most common for customers.
- Solution partner insights - our solution partners help us better understand real-world customer deployments, especially for customers at scale.
- Product analytics - analytics are used from Cloud customers and opted-in Server customers, which helps us understand how existing features are being used.
- Product strategy - our long-term strategic vision for the product.
Our features workflow
We use the Suggestion issue type for improvements and feature requests.
We have standardized our workflow statuses across products to make it easy for you to see where an issue is at. Here’s the current workflow, and a description of each status:
This issue is waiting to gather more customer interest, before being reviewed by a member of the Atlassian product team.
|Reviewing||This issue is being investigated in-depth by a member of the Atlassian product team.|
|Under consideration||This issue is a strong candidate for our roadmap. We’ll follow up on it in a few months time.|
|Future consideration||This issue is a potential candidate for our long term roadmap. We won't work on it in the short term, but will review it again within a year.|
Not Being Considered
We appreciate the merit of this issue, but don't intend to work it in the foreseeable future. We'll review it again within a year to see if our decision has changed.
|In progress||The development team is currently working on this issue.|
|Waiting for release|
The change has been implemented and is waiting to be shipped in a release. The Fix Version field will indicate the product version that will contain the change.
Work on this issue is complete. If the change has been implemented, the resolution will be 'Fixed' and the Fix Version field will indicate the product version that contains the change.
If we don't intend to implement this change, the resolution will be 'Won't fix', ‘Duplicate', 'Timed out', or similar.
For a product manager's perspective on this workflow, see An updated workflow for Server feature suggestions on Atlassian Community.
How to get new features and improvements
To get access to new features and improvements for Server and Data Center products, you will need to upgrade to a release that contains the change.
To make understanding our bug fix policy easier, here's some definitions.
- Platform release (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 (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.
- Bug fix release (4.6.2) can contain bug fixes, stability and performance improvements. Depending on the nature of the bug 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 bug fix 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 Server and 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 organisation. For Jira Software and Confluence 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 endeavour to allow zero downtime upgrades between one Long Term Support release and the next Long Term Support release, but can't guarantee that down time will not be required, depending on the nature of the changes. The change log will indicate if 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.