Bug Fixing Policy

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Summary

  • Our Support team will help with workarounds and bug reporting
  • We'll generally fix critical bugs in the next maintenance release
  • We schedule non-critical bugs according to a variety of considerations

Report a bug

Building an add-on

Are you developing an add-on for an Atlassian product or using one of our APIs? Report any related bugs here.

On this page:

Bug reports

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

Use our issue tracker to search for existing bugs, and watch the ones that are important to you. When you watch an issue, we'll send you an e-mail notification when the issue's updated.

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.

Release terminology

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

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.




Further reading

See Atlassian Support Offerings for more support-related information.

Last modified on Mar 5, 2012

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.