Building upon last month's blog, we have an update on our plans to ship breaking changes across Server Products. While plans often change, we do our best to be open about our work so the Atlassian Ecosystem can plan ahead to ensure a smooth experience for our customers. We've consolidated these updates into a single, easy to digest, post and will provide monthly updates until the end of the year.
We have some exciting new features lined up for the Bitbucket Server 6.0, with a planned release in late January, 2019. We also plan to release an Early Access Program (EAP) Bitbucket Server 6.0 release, including all breaking changes, in the first week or so of 2019.
For one of the features in Bitbucket Server 6.0, we need to deprecate direct access to repositories on disk for apps. You can find all the necessary details in the API changelog. We're also going to remove the notification handler plugin point, and the related notification API. When you need to send notifications just listen for the event you are interested in using a listener based on that specific event, and get the recipients via com.atlassian.bitbucket.watcher.WatcherService to send notifications.
We're going to add support for Java 11 in Bitbucket Server 6.0, as Java 8 is reaching end of life in January, 2019. After Java 8 reaches end of life, unless an Oracle Java 8 subscription is purchased, no further fixes, including security patches, will be available for it. As a core dependency for Bitbucket Server, such patches are critical, so we're adding support for Java 11.
We'll also end support for PostgreSQL 9.2, which has been deprecated since the Bitbucket Server 5.7 release (see the supported platforms page for details).
We're going to end support for all versions of Git prior to Git 2.11:
- Versions prior to Bitbucket Server 6.0 support Git 2.2.0 and newer, excluding Git 2.12.2 on Windows (see the supported platforms page for details).
- After 6.0 we will require Git 2.11.0 or newer, excluding Git 2.12.2 on Windows.
Starting from Bitbucket Server 6.0 custom file handlers will no longer be used for rendering diffs, only for source views.
bitbucket.internal) have never been supported as API but they
will be unavailable from 6.0 onwards.
TextView.api (which has been hidden behind an unsupported
internal event since 4.0) will also no longer be available. This includes
DiffView.registerGutter for adding extra information to the diff gutter.
Instead we recommend using
to add extra information to the diff.
Confluence 6.13 is now released, and brings with it support for AdoptOpenJDK 8, as an alternative to the paid Oracle JDK. Full Java 11 support is planned to be delivered with Confluence 7.0 sometime in 2019.
We have also added the ability to permanently delete a user account and anonymise the personally identifiable information associated with it. If your app displays people's names or usernames (think places like mentions, or the page byline), you should test how it behaves when a user has been deleted. Check out the release notes and preparing for Confluence 6.13 for more details. Confluence 6.13 will be our next Enterprise release line.
We are continuing our work on the TinyMCE editor upgrade from 3.x to 4.x. This has been ongoing for some time now and hopefully everyone has checked their apps for compatibility. If not, check out how to test your add on with the upgraded TinyMCE4 editor. We expect that this will land in 6.14.
Confluence Server 7.0 scope, in addition to full Java 11 support is likely to include, upgrading Guava and AUI. We will be removing some very old and deprecated code from 1.x through 4.x releases. We also have a number of planned changes in Confluence 7.0 regarding removal of unused features. Formal end of support announcements will be made closer to the release of Confluence 7.0
We are also working on a new Search experience to replace the existing Quick Search experience (what is quick search?). If you have an app which interacts with the search experience, check out preparing for Confluence 6.14 for more details.
Jira Software Server
We are continuing our work on Jira Software 8.0. The release has now been moved to the end of January 2019.
If you haven't started following our Jira Software 8.0 EAP program, we highly recommend taking a look at the most recently released version. More information on the 8.0 Early Access Program can be found here.
The Jira Software 8.0 release will include:
- Improvements to the search sub-system via a Lucene upgrade
- Frontend improvements such as jQuery library updates and deprecation of global variables in favor of AMD modules (for more details, see this post (private marketplace vendor forum))
- Agile and Kanban board performance improvements
- An upgrade to use new Java 11-compatible platform components and libraries
- Several other end-user features, which will be unveiled closer to the release
8.0 Beta and Release Candidate
The beta version of 8.0 has been released. This version is feature complete but as we discover and fix bugs, some minor changes might still occur.
We expect to release a Release Candidate version roughly two weeks before the final release. This will be the same build we plan to release as the final version, and will give an opportunity to app vendors to test with the final release build before it is released to customers.
Jira 8.0 will be compatible with Oracle JDK 8 and OpenJDK 11. This means that Java 11 features will not be supported in the source code (Java 8 compatibility mode). Hence, we will only announce limited Java 11 support without making Jira officially compatible with Java 11 until a future 8.x release. This will give app vendors time to update their products before we announce official compatibility with Java 11. Most likely, this will take place sometime in Q1 2019. After we announce the official compatibility with Java 11, we will also plan to have OpenJDK 11 bundled with the Jira installer.
We continue to work towards Jira Service Desk 4.0 and in service to that the new EAP is available now. We�ve removed com.atlassian.fugue from our automation API and SPI, and updated them to use Core Java Data types and Exceptions instead. You will need to update any automation-specific scripts, integrations or apps to use the new API and SPI. For more details and EAP access, please visit this page.
The frontend platform team are responsible for maintaining and improving a number of projects that power the frontend of Atlassian Server products. The platform is frequently bundled in and provided by Server products. This means that, most of the time, any breaking changes announced by the frontend platform team will first need to be adopted by Server products before the community will need to adapt to them. However, it is worthwhile for us to get the signal to you sooner, in the spirit of Open Company, No Bullshit.
The final version of AUI 8.0 has been released. Head to our community post for the announcement and links to further resources and answers to common questions.
AUI 8.x will receive development and maintenance throughout FY19. AUI 7.x will receive occasional updates and maintenance throughout FY19.
Found a bug? Raise a ticket in the AUI project on our Ecosystem Jira.
Web Resource Manager (the WRM)
WRM v4 includes the following backwards-incompatible changes:
- Asynchronous requests for resources can now pull in resources if they are referenced through the superbatch.
The superbatch is only excluded from requests automatically if it was drained previously. WRM v4 also removes support for Internet Explorer 10 and lower.
The ability to conditionally output web-resources to Internet Explorer has been removed.
<resource>blocks with either an
conditionalCommentparam will not be rendered at all.
What these changes mean for app developers:
- If your apps no longer support IE 8 or 9, you can safely remove all resources using these params, as they were never rendered in IE 10 or 11.
- If you use include resources asynchronously (i.e., you use the WRM.require API), you may need to review the resources you request, as the payload may change slightly � you may receive more resources than in v3, but in most cases, the v4 response is a better, more accurate representation of every resource your code actually needs.
Questions? Please raise a ticket in the Ecosystem Developer Service Desk