Atlassian Bug Fixing Policy
Atlassian Support is eager and happy to help verify bugs—we take pride in it! Create an issue in our support system, providing as much information as you can about how to replicate the problem you're experiencing. We'll replicate the bug to verify, then lodge the report for you. We'll also try to construct workarounds if possible.
Search existing bug reports
How we approach bug fixing
Bug fix releases come out more frequently than feature releases, and attempt to target the most critical bugs affecting our customers. The notation for a bug fix release is the final number in the version (the 1 in 6.0.1, for example).
If a bug is critical (production application down or major malfunction causing business revenue loss or high numbers of staff unable to perform their normal functions) we'll fix it in the next bug fix release, provided that:
- The fix is technically feasible (it doesn't require a major architectural change)
- It doesn't impact the quality or integrity of a product
Non-critical bugs are prioritised by these factors:
- How many of our supported configurations are affected by the problem
- Whether there is an effective workaround or patch
- How difficult the issue is to fix
- Whether many bugs in one area can be fixed at one time
Teams responsible for fixing bugs also monitor comments on existing and new bugs, so you can comment to provide feedback if you need to. We give high priority to security issues.
When considering the priority of a non-critical bug, we try to determine a value score for a bug. The score takes into account the severity of the bug from our customers' perspective, how prevalent the bug is, and whether new features on our roadmap may render the bug obsolete. Our developers combine the value score with a complexity score (how difficult the bug is) when selecting issues to work on.
How to get access to bug fixes
To get access to bug fixes you will need to upgrade to a release that contains the fix.
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 (3.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 (3.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 an Enterprise release, which means it will recieve bug fixes for a longer period of time than a standard feature release.
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, an Enterprise release may be a good fit for your organisation. For Jira Software and Confluence we will:
- Designate a feature release as an Enterprise 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 Enterprise 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 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 Enterprise release and the next Enterprise 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 an Enterprise release. The number of bug fix releases and timing illustrated below is just an example, your product's release cadence may differ.