Preparing for Jira Software 10.0 and Jira Service Management 6.0 - multiple EAPs coming your way

Jira Development Jira Data Center
, , , ,
1

We are excited to share our plans for the upcoming JSW 10.0/JSM 6.0 Data Center platform release. As a reminder, a platform release often includes multiple breaking changes that establish the foundation for continued improvement in future 10.x/6.x feature releases.

JSW 10.0/JSM 6.0 primarily aim to reduce the number of exposed dependencies, enabling a timely and efficient resolution of security issues. Additionally, it involves upgrading the JSW & JSM technology stack by uplifting dependencies and transitioning to Java 17. Please note that as the development of the release is underway, the specifics of breaking changes will evolve.

Predicted scope of breaking changes

This is our best estimate of areas with breaking changes at this point. Our Early Access Program releases (EAP) will contain the scope of breaking changes in JSW 10.0/JSM 6.0 along with supporting documentation with more details and specifics. Several platform and security upgrades are planned for JSW 10.0/JSM 6.0.

Platform 7 upgrade

JSW 10/JSM 6 will mainly (but not limit to) focus on upgrading to the new Atlassian DC Platform 7.

For more information on the changes in Data Center Platform 7.0 visit ā†’ Announcing Data Center Platform 7.0. Next step to improve our security posture

Supported platform changes

With this release, JSW & JSM will use OpenJDK 17 as the default. Support for JDK 8 and 11 will be removed. We will also be removing support for the H2 embedded database.

Removal of Deprecated Avatar and Attachment APIs

In this release, we will be removing the deprecated public APIs that allowed direct filesystem access to avatars and attachments. These APIs have been marked as deprecated since Jira 9.7 or earlier, and their removal in Jira 10 was announced with the Jira 9.7 release. Additionally, we will eliminate the feature flag required for using the Storing attachments in Amazon S3 feature.

Test with EAP releases

Early Access Program releases are designed to provide visibility and an opportunity to develop against the changes of the upcoming platform release. Between now and the JSW 10.0/JSM 6.0 release, we plan to have multiple EAP releases (including an EAP Beta and the EAP Release Candidate) containing breaking changes, bug fixes, and improvements. We plan to release the first EAP in mid-February 2024.

Weā€™ll communicate ahead of the following EAP release and do our best to include most of the planned breaking changes as early as possible to give you enough time to schedule changes to your app before the official JSW 10.0/JSM 6.0 release.

Frequently Asked Questions (FAQs)

We know that a platform release can provide many unknowns. Here are some questions we wanted to address with our current information.

When will JSW 10.0 / JSM 6.0 arrive?

We canā€™t provide an exact date, but our current target to release JSW 10.0/JSM 6.0 is Q2 or Q3-2024.

Will there be breaking changes to Jiraā€™s APIs?

Yes, and we are still working on the full scope of breaking changes to the REST API or Java API. As those breaking changes are scoped, we will add more detail to this post in the future.

Are there any restrictions on who has access to the EAP builds of JSW 10.0/JSM 6.0?

No, there will not be any restrictions. The EAP is open to everyone.

Will there be additional resources to help us prepare?

Yes! In coordination with the EAP programs, we will provide more detail about breaking changes and the technical scope of JSW 10.0/JSM 6.0. We will also have technical documentation on detail how to adopt the changes to Jira. Weā€™ll be publishing all the documentation on the EAP page.

Weā€™re looking forward to hearing your feedback.

Best,

The Jira team

2 Likes
2

Let me get this straight: youā€™re aiming to release the first EAP around mid-February and to have a GA release Q2 or Q3 and you donā€™t know yet which breaking changes youā€™re going to introduce?

Marketplace partners are expected to upgrade to fork their codebase (Jira 9 LTS isnā€™t going anywhere) to support Jira 10, upgrade the toolchain to Java 17, test whatever gets broken by those yet unknown breaking changes and keep reading posts here and there to find out what is going to change?

Itā€™s extremely disappointing that you donā€™t have a list of what is going to break: itā€™s possible that some features might just stop working with the removal of some APIs or with some components getting hidden from OSGi and there wonā€™t be a replacement.

We are essentially going to spend a quarter working on unknown stuff and possibly having to remove existing features.
This is a lot of work in a short time. Smaller apps might make it work, but for large products this is only feasible if you take the time to give real summaries of what youā€™re going to change in advance.

If we donā€™t get before each EAP a detailed list of what classes/packages arenā€™t going to be available anymore, which dependencies are getting removedā€¦ it will be a mess and weā€™ll always have to try and catch up with whatever got broken. Itā€™s just not reasonable: I expect to be able to make my changes in advance and just test that everything works as expected in the EAP.
Moreover, if we have to kill existing features due to removed APIs, we need the time to come up with alternatives or to communicate it to our existing customers.

This is already going to be a significant cost for marketplace partners, please spend some resources to keep it from becoming unsustainable.

22 Likes
3

Will there be product source downloads for the EAPs? Iā€™m asking because ā€“ as you probably know ā€“ source downloads are not readily available for some time now; only individually via creating support-requests with Atlassian.
Having product sources available would greatly help with working towards compatibility.

9 Likes
4

How will the development setup look like with no H2 support? Additional steps for spinning up a database?

What about app compatibility with older Jira versions when Java 8 and 11 are dropped?

Thanks,
Fredrik

4 Likes
5

Iā€™d strongly recommend using Docker-based development with postgres/mysql. You can even have QuickReload. It is a lot faster compared to atlas-debug and will also allow you to develop against a production-like instance.

Here is an example on how to set it up:

11 Likes
6

Hi @remie
Does it require atlas-mvn package if I only change Javascript files?

7

Yes, unfortunately it does. I have never gotten hot reload to work with QuickReload. There is a whole thread about it here: Problem with the hot-reload in Atlassian WRM webpack plugin (for Data Center)

2 Likes
8

h2 removal impact integrations tests too :slightly_frowning_face:

1 Like
9

Thanks for this tip @remie
Do you also use docker for integration testing?

10

Yes, the GA is planned around Q2-Q3. Weā€™re going to have multiple EAPs along this time and work with the community on the reported feedback just like we did with JSW 9.0 and JSM 5.0

WRT to scope, most of the breaking changes are related to Platform 7 mentioned

A list of JSW & JSM-related items is coming as weā€™re working in parallel on the Platform 7 adoption. Within the first JSW & JSM EAP were planning to expose these changes:

Comprehensive list will be included in the EAP changelog soon.

WRT communication the changelog is the standard way of getting the most accurate info about the early access program scope and tech details, and we will utilise it to the greatest extent. We decided to include additional posts on the dev community to enhance communication. Along with each JSW JSM eap, we will give you as much insight and documentation into the included changes as possible.

11

Currently, we foresee no changes to the policy regarding the sharing of source code.

12

Based on our knowledge and internal testing, apps complied on Java 8 should work. We did tests with bundled Atlassian apps, and they were OK. We also smoke-tested a few Marketplace apps with Jira compiled in Java 17 and saw no significant problems. That being said, we strongly advise you to run your comprehensive testing once the EAP is out.

1 Like
13

@AndrzejKotas, playing dumb here: You mean the policy as stated on https://www.atlassian.com/licensing/purchase-licensing#who-has-access-to-product-source-code ?

Source code access is available only to the nominated technical and billing contacts of a Server/Data Center product license.

According to that publicly stated policy, we ā€“ as holders of Data Center licenses ā€“ should have access to product source code.

Atlassian may need to update that page, if you indeed foresee no changes to the current situation :confused:

1 Like
14

Sorry for confusion, Iā€™m referring to the fact that access to source code was restricted as a security measure in response to the advisories e.g. CVE-2023-22515.

15

For what itā€™s worth it has been very easy for me to get access to the source code as a customer by opening tickets with the PSSRV team and Iā€™ve never waited more than 24 hours. I definitely donā€™t like the delay but Iā€™ve still been able to do my job.

2 Likes
16

As we are excited for the platform changes and modernization and eager to stay tuned and compatible, I have been frustrated with the gatekeeping and bureaucracy on source code lately. I am posting feedback to the Atlassian security team, and would love to get their response about the reasoning behind this security through obscurity strategy. Does the Atlassian security team suggest that ā€œnation-state actors actively exploiting CVE-2023-22515ā€ do not know how to use decompilers?

Withholding source code is useless as an actual security measure that is to be relied upon for safety (beyond the feeling/illusion of safety). As long as the binaries are available for download, the bytecode is there, packed into the binary. The bytecode represents the program, and the original sources can be fairly well reconstructed with a little effort, to a degree where vulnerabilities can be identified and exploited if they are present. That the source code download has been restricted does not matter much for a threat agentā€™s ability to wreak havok.

Instead, what this ā€œsecurity measureā€ is doing, is to create a lot of extra work for all of us honest parties (including Atlassianā€™s own support agents spending all this time distributing sources in N tickets). In no meaningful way is this improving security or preventing bad actors from exploiting CVEs. I encourage the Atlassian security team to read some research on decompilers and code reverse engineering, like the article by Hamilton (2009), and kindly ask them to reconsider their current restricted source code policy if it indeed is security that is the reason for withholding code.

References
Hamilton, J. (2009). Decompiling Java. MPhil Transfer Report, Goldsmiths, University of London.

8 Likes
17

Even that would be silly. ā€œNation-state actorsā€ can just buy a Jira license and ask Atlassian for the source code with a support request. Depending on the nation, they might not even need to use a fake company.

4 Likes
18

While I cannot get into the details around the decision, I have made sure to share your thoughts @EliasBrattliSorensen with the wider security team.

3 Likes
19

Thank you for sharing my message and getting back @AndrzejKotas :pray:

20

Hello all. I want to update you on the first early access program. Unfortunately, we were overly optimistic about our ability to adopt the first milestone of Platform with Rest v2 and ensure quality, and it requires a bit more work. We know we promised the EAP build in February, but by the looks of things, this is likely to slip in 1-2 weeks. Apologies for that, and we will keep you posted with more info soon. The Jira team

7 Likes