Upgrading to a new product release is a process that might seem like routine housekeeping, but, as our seasoned Atlassian administrators know, can have a number of complexities and require plenty of strategy and foresight.
Between apps and the (sometimes) tens of thousands of end users you have, the prospect of upgrading to a new release can be a major initiative requiring significant planning. While some of our Server and Data Center customers love to jump on the latest release as quickly as possible to get new features and performance improvements, others take a more measured approach to upgrading.
At Atlassian, we’ve been shipping Server product releases to customers for a long time. At each step of our journey, we’ve listened to your feedback on our releases and worked to incorporate that knowledge into a release structure that works better for you. This input has translated into iterations on our release approach, changes to our release cadence, the introduction of new packaging like Starter licenses, the formation of new products like Jira Service Desk, and even to the rollout of new offerings like Atlassian Data Center. This journey and our evolution is ongoing: products like Jira Software and Confluence have matured and your deployments have gotten bigger and increasingly mission critical. There are new challenges that you face today that were not as important in the past.
Specifically, we have seen deployments of our products for some of our customers grow in both scale and complexity. For these larger customers, an upgrade to a new release of Jira Software or Confluence can take weeks, or even months, to ensure that apps don’t break and that there is no unexpected feature or performance impact for their users. While we’ve worked to make this process easier by reducing planned downtime with features like Zero Downtime Upgrades for Jira Software, it’s still a complex effort.
Some of our customers have been asking to be able to stay on a feature release for a longer period of time between upgrades with the assurance that they can get important bug fixes, both security and otherwise. In fact, this has already happened with customers using Atlassian’s Premier Support. Premier Support created a notion of a “Premier Support recommended version” to help guide our customers with complex upgrade needs, and we’ve been back-porting fixes to these recommended versions.
At the same time, we are moving to a faster release cadence across our Server products with the goal of delivering more product improvements, faster, that are of higher quality. With all of these changes, we believe this is the right time to revisit our overall approach to product releases and how we can better support you, so you can better plan your upgrades and meet the needs of your users.
First, an important note on release terminology
We’ve used a variety of terms to refer to different types of releases over the years: everything from major and minor to bug fix, platform, “dot oh”, and more. This is confusing to you, our customers, and it is even confusing to us internally at Atlassian. To make understanding our release process easier, you will see us using the following terminology in future communications:
Platform release (e.g. Confluence 6.0) contains significant or breaking changes. This might include changes to or the removal of existing APIs, significant changes to the user experience, or a new major feature.
Feature release (e.g. Confluence 6.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 (e.g. Confluence 6.6.2) can contain bug fixes, stability and performance improvements. They may introduce minor changes to existing features, but do not include new features or high-risk changes. We recommend regularly upgrading to the latest bug fix release for your current version. These were previously referred to as ‘maintenance’ releases by some products.
In addition to the three main release types, a feature release can also be designated a Long Term Support release, which means it will receive backported critical product bug fixes and security bug fixes for a longer period of time than a standard feature release..
Introducing Long Term Support releases for Jira Software and Confluence
We are introducing the concept of a Long Term Support release for Jira Software and Confluence Server and Data Center products. Our first Long Term Support release versions are Jira Software 7.6 and Confluence 6.6.
The goal is to allow you to upgrade to a feature release (e.g. Confluence 6.6) that you know will get critical bug fixes, without requiring you to upgrade to the latest feature release. The Long Term Support release designation is intended for customers who are already upgrading in this way today, tackling complex deployments of their products with careful planning and plenty of lead time. For customers who prefer to upgrade more frequently and stay on top of the latest releases and features, we don’t want to slow you down! Please continue to expect faster releases and more incremental value for you and your end users.
At least one feature release (e.g. 6.6) every year will be designated as a Long Term Support release. Our plans will be announced at the time of the initial feature release. This will enable customers to start preparing for their upgrades. We will officially declare it as a Long Term Support release at a subsequent bug fix release (e.g. 6.6.2)—this will allow further validation as you prepare to deploy in production.
This does not change our support window for releases, meaning a Long Term Support release will be supported for the same period of time as outlined in the Atlassian Support End of Life Policy, which is 2 years. But it does allow our larger enterprise customers, for whom upgrades can be a significant deployment hurdle, to move to a Long Term Support release and stay on it for a year or more depending on when they upgrade to it. For customers on Premier Support, the Long Term Support releases are a replacement for “Premier Support recommended version”—there will no longer be a separate designation of releases for our Premier Support customers.
What’s unique about a Long Term Support release?
Long Term Support releases will receive additional support and documentation from the Atlassian team, to make the process of upgrading easier. For each Long Term Support release, we will include:
- Back-ported security bugs as defined in our security bug fix policy.
- Any bugs that we deem critical and that we would normally fix in the next bug fix release of the product per our bug fixing policy. These will generally be issues relating to stability, data integrity, or critical performance issues with a specific focus on regressions where core product functionality breaks.
- A combined change log from the last Long Term Support release of the product so you can more easily understand what new capabilities have been introduced.
- Scale and performance benchmarks relative to the prior Long Term Support release of the product.
It’s possible that we may not be able to back-port certain bugs due to the complexity of the fix or a significant regression impact. Some examples of this are library upgrades (e.g. the caching library, Hazelcast, used in Confluence or the indexing library, Lucene, used in Jira), or major architectural changes to our caching and indexing architecture. In addition, we will not back-port fixes that impact API or change code used by third-party apps—those changes are reserved for platform releases (e.g. 6.0). In cases where we cannot back-port a bug, we will provide an explanation as well as outline alternatives available to our customers.
Additionally, we will continue to support Zero Downtime Upgrades (ZDU) for Jira Software Data Center on bug fix release upgrades (e.g. from 7.6.5 to 7.6.6), but only target ZDU for feature release upgrades from one Long Term Support release to the next. However, even when upgrading from one Long Term Support release to the next, there may be situations where, in order to make certain performance or stability improvements, we may not be able to support ZDU. Our goal with ZDU is to minimize planned downtime during upgrades but any necessary performance or stability improvements will take precedence. We will not take breaking ZDU lightly. Ultimately, we want to make sure we are making the right trade-offs based on your needs.
Finally, as part of this shift, we will also update our Security Bug Fix Policy for non-Long Term Support releases of Jira Software Server and Confluence Server. As we move to a faster release cadence for Jira Software Server and Confluence Server, we are updating the window where we back-port critical vulnerabilities for previous feature releases that are not Long Term Support release to release dates within 6 months (this is similar to Bitbucket Server.) Of course, critical vulnerabilities will be back-ported to all Long Term Support releases in the support window.
How can you get started?
We are excited to announce that we plan to designate Jira Software 7.6 and Confluence 6.6 as our first Long Term Support release versions. We are currently getting further validation for those releases so we can officially declare them as Long Term Support releases in the near future.
Additionally, for Jira Software, since many larger deployments are on the current Premier Support recommended version 7.2, we will continue to evaluate back-porting critical bugs in that version’s remaining support window.
Update: Since this post was originally published, Jira Software 7.6 and Confluence 6.6 have been declared Long Term Support releases. Please let us know if you have any questions or comments in this community post.