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


Developing an app (add-on) for an Atlassian product or using one of our APIs? Report any related bugs in our Ecosystem Jira.

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 are more frequent than feature releases, and target the most critical bugs affecting customers. The notation for a bug fix release is the final number in the version (the 1 in 6.0.1, for example).

We assess each bug based on the symptom severity (that is, when this bug causes symptoms, how severe are those symptoms). There are three levels of symptom severity.

Severity 1 - Critical

Your application is unavailable. Users aren't able to perform their job function, and no workarounds are available. 

See some examples...
  • login failure affecting all users
  • all or most pages don't display
  • out of memory errors cause application failure
  • significant data loss
  • node communication failures
  • administration tools fail. 

Severity 2 - Major

A feature is unavailable, application performance is significantly degraded, or users job functions are impaired.

See some examples...
  • the application performs slowly and fails intermittently
  • application is functional, but frequently used gadgets or macros don't work
  • application links fail
  • specific editing features fail
  • or a Severity 1 (critical) issue where there is a viable workaround. 

Severity 3 - Minor

The application or specific feature isn't working as expected, but there is a workaround available. Users experience is impacted, but their job function is not impaired. 

See some examples...
  • some searches fail
  • sections of pages load slowly
  • administrative features fail intermittently, but a workaround is available
  • visual defects, that don't affect function
  • minor translation or localization problems
  • keyboard shortcuts not functioning as expected.


Assessing bugs using symptom severity makes sure that we prioritise the most impactful fixes. We give high priority to security issues.

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 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 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 Jul 9, 2017

Was this helpful?

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