Jira seasonal releases and Release tracks: What Cloud admins need to know

[#1]

Following Atlassian’s recent announcement about Jira moving to seasonal releases to provide better predictability, reduce surprises, and ensure a higher-quality experience when features land (Coming soon: Jira seasonal releases), we want to share more detail on how this will work for Cloud Premium and Enterprise customers using Release Tracks—specifically, when major user-visible changes will land in Sandbox and Production environments for Jira.

When to expect seasonal releases with Release Tracks

Seasonal releases	Availability for Continuous tracks (Production environment)	Availability for Preview tracks (Sandbox environments)	Availability for Bundled tracks (Production environments)
Spring (Team’26)	Late April	Early May	Early June
Summer	Late July	Early August	Early September
Autumn (Team’26 Europe)	October*	November*	December*

*Tentative timing aligned to Team ’26 Europe; exact dates will be confirmed at a later time.

Customers using Preview & Bundled release tracks

• If your Jira Sandbox environment uses the Preview release track and your Jira production environments use Bundled release tracks:

  • New changes included in the seasonal release will first roll out to Sandbox environments on the Preview release track in early May, giving you time for testing and preparation.

  • Those same changes will then be released to Production environments on Bundled release tracks in early June.

Customers using Continuous release tracks

• If your Jira production environments are on the Continuous release track, you’ll receive new features on the published seasonal release cadence. The first seasonal release in this new format is expected to land in your production environments around Team ’26.
  
  

How to prepare for upcoming seasonal releases with Release Tracks

If your Production environment is on a Bundled release track and your Sandbox is on the Preview track:

• You will continue to receive a 30‑day testing and preparation window between the Sandbox release and the corresponding Production release.

• Seasonal releases will likely contain more changes at once than previous monthly bundles. We recommend:

  • Planning ahead for test cycles, UAT, and stakeholder reviews during that 30‑day window.

  • Reviewing upcoming changes early in App updates and identifying any high‑impact changes that may require additional preparation or validation.

We’re also working on new admin capabilities that will extend the testing window for new releases beyond the current 30 days. If you’re interested in early information and in providing feedback on these improvements, sign up here and we’ll reach out when we have more to share.

Have questions or feedback?

To go deeper on Jira seasonal releases, check out the announcement blog or share your thoughts and feedback in the comments below!

---

FAQ

Will Release tracks only have 3 Jira releases a year?
No. Jira Bundled and Preview release tracks will still have 12 bundles per year. However, all significant user‑visible changes will only be included in the 3 key seasonal Bundled releases in June, September, and December.

What will be included in the other Release track bundles?
Bundles outside the June, September, and December seasonal Bundled releases may:

• Contain small or low‑impact user‑visible changes, or

• Contain no user‑visible changes at all.

For a bundle‑by‑bundle view of what’s included, go to the Bundled release tracks tab under App updates in admin.atlassian.com.

Which Atlassian apps are included?
Right now, these changes apply only to Jira (software projects and business projects). There are no immediate changes to how Release tracks work for:

• Other Jira family products (for example, Jira Service Management, Jira Product Discovery), or

• Other Atlassian apps such as Confluence.

We’re keen to hear your feedback as we explore extending this seasonal release approach to additional Atlassian products.

What’s the advantage of using Preview & Bundled Release tracks versus Continuous release tracks?
Using Preview for your Sandbox and Bundled for your Production environment together provides a consistent 30‑day testing and preparation window between when changes land in Sandbox and when they roll out to Production.

If you instead use Continuous release tracks for Production, new changes are delivered directly to Production at the seasonal release rollout time with no built‑in testing window, which may reduce the time you have for validation, change management, and communication.

Where can I find release notes for Jira seasonal releases and Release tracks bundles?
App updates in admin.atlassian.com is currently the best place for org admins to view detailed release notes for changes included in Jira seasonal releases, as well as other Atlassian apps. Organizations using Bundled release tracks can also see the latest features included in each bundle from the Bundled release tracks tab in App updates.

We’ll be making additional improvements in the coming months to make App updates available to a wider audience and to better highlight new changes associated with Jira seasonal releases.

[Ben Robbins]

Can you please stop using google docs for signup forms (https://docs.google.com/forms/d/e/1FAIpQLScDVtz4zHiEALi3WQczuSQigJtZdWzU9U3QTwthN5BFoDLBdQ/viewform?usp=dialog). Pretty certain I won't be the only one who cannot access this due to my company's information security policies.

[Stephen.Lugton]

Thanks @Alex Chiu for this update, I see you've gone for season names for this, is there any particular reason for excluding so many users by using names that don't match the season in the southern hemisphere rather than using fully inclusive names?

Also, why have you gone for 3 months between releases, then another 3 months between release, then 6 months?  Is it just so that it matches up to Teams' US and Teams' EU?

[Josh]

Hi @Alex Chiu . Thank you for the helpful clarifications!

Regarding this part:

Which Atlassian apps are included?
Right now, these changes apply only to Jira (software projects and business projects). There are no immediate changes to how Release tracks work for:

• Other Jira family products (for example, Jira Service Management, Jira Product Discovery), or

• Other Atlassian apps such as Confluence.

We’re keen to hear your feedback as we explore extending this seasonal release approach to additional Atlassian products.

It's arguably adding *more* complexity to an already complex situation for orgs that use multiple products in the Jira family (e.g. JSM or JPD). If you're going to go this way, could you please get the other Jira family teams onboard before rolling this out? The continued separation between how Jira, JSM, and JPD work on a foundational level has been making life a lot harder for admins and users. I get that the products need to differentiate themselves, which is totally fine for unique features and functionalities, but the common elements should be the same across the board.

[Carolyn White]

I'm not sure about other companies, but we have a lot of activity in December and that is not the time to introduce changes. Changing processes while multiple projects are finalizing year end reports and enhancements will not be received well. I understand that annual conventions is a great time to introduce the biggest changes coming, but if December/January becomes a set-in-stone release time, could you at least make that release less intrusive and perhaps a little lighter than the others?

[Mathew Lederman]

I am in violent agreement with @Carolyn White. My organization has enterprise-wide change moratoriums during December and January. This is an awful time to make changes.

Additionally, in many organizations (and countries) employees take off in mid/late December and early January. How are admins expected to support and communicate a change when half the organization is OoO?

Like @Ben Robbins my organization blocks Google Docs. Please use a proper sign-up tool, or maybe a ticketing system if you're familiar with one...

Finally, as I asked on the original post with this information and have not yet received a response, where will the details be posted? On one of the 8 places admins have to track for Atlassian changes today? Or are we adding more fun to the mix?

[__ Jimi Wikman]

Am I understanding this correctly that Atlassian thinks that bigger UI changes, like the navigation changes or changes to namings, are something that all organisations can evaluate, test, and rollout to their organisation...in 30 days?

We are now talking about changing workprocesses and methodologies for hundreds, if not thousands, of people. This, of course, is if we are on the bundled tracks. Otehrwise if will be "surprise Mother....er!!" as usual?

May I suggest that the new admin capabilities allow for more than a 30-day push, and that you add the ability to stagger these releases quite a bit. Like people have said december is a bad time for releases, and for many, July is when everyone is away, so no one will actually be around to even handle that one...

While I applaud you for realising that the current releasemanagement is pretty bad due to the scale of changes and the lack of visibility of changes, I think there is room for improvement here.

--

I also think that maybe we, as customers, have to consider the impact on the Atlassian side as well. Staggering releases does not just mean that the bigger things can hold before we implement them. Every release of functionality that comes afterwards that depends on the code we are pausing also has to be staggered.

That is a lot of extra work to manage conflicts within the codebase and work with feature flags connected to those conflicts. We are talking about a cascade effect here that will undoubtedly result in more bugs and a more unstable platform. The more we stagger, the more dependencies have to be tracked and managed by Atlassian.

In the best case, we would have controlled release windows, just like you have in DC, where code is packaged in releases, and you have to add them in sequence. When it is added does not really matter, but you have to add them one by one in sequence, as all following features are dependent on the previous one.

The way we as customers can easily plan our release windows whenever we want, and Atlassian would not be forced to have this big matrix of dependencies for connecting CI/CD releases with planned releases...

[Alex Chiu]

Hi @Ben Robbins & @Mathew Lederman

Thanks for the suggestion! Google Forms is one of the tools we use today to gather initial interest. Once we get closer to early access, we’ll provide an actual signup portal through our legal consent management center instead.

Happy to share the signup link here once it’s available.

[Alex Chiu]

Hi @Stephen.Lugton 

Thanks for the feedback on the naming of the seasonal releases and really appreciate you sharing your perspective. Happy to pass these feedback back to our partners in the Jira team.

You’re right that these releases roughly align with our TEAM and TEAM EU events, with an additional release in between. For more details on seasonal release timing, please refer to the original announcement blog.

[Alex Chiu]

Hi @Josh 

Thanks for your feedback — I definitely understand that these changes will introduce some additional operational complexity.

As mentioned in the original announcement blog, our broader ambition is to scale this model beyond Jira. The goal is to first prove the customer benefits of the seasonal release approach with Jira, and then extend it to other Atlassian products over time.

[Alex Chiu]

Hi @Carolyn White & @Mathew Lederman 

Thank you both for sharing your feedback on the timing of the final seasonal release of the year — that’s really helpful context. I’ll make sure to pass this along to our partners in the Jira team.

[Alex Chiu]

Hi @Mathew Lederman  

If your organization is using Release tracks, the Jira Bundles tab in App updates at admin.atlassian.com is the best place to preview which changes are included in the seasonal bundles before they are released.

I completely understand your concern about having to check multiple places to stay on top of Atlassian changes. One of my team’s goals this year is to consolidate some of the surfaces you listed and ensure the same key information is shared more broadly and evenly so we can improve awareness and reduce admin overhead. Stay tuned — we’ll have more to share on this soon.

[Alex Chiu]

Hi @__ Jimi Wikman 

Thank you for your detailed comment and the additional context — this is extremely helpful, and I'll be sure to share this more broadly internally with our partner teams in Jira and other product teams.

As mentioned in the post, we know that for customers with more complex requirements, 30 days is often not enough time to test and prepare. We’re actively working on improving this testing window so customers have more time to get ready for upcoming changes.

Please stay tuned here — we’ll share more details as soon as we have concrete plans to announce.

[Rune Rasmussen]

Having loudly complained about Atlassians update and communication strategy on every possible occasion I very much applaud the intent and attempt at making it more streamlined and unified.

This could be quite good, eventually.

But... Until all your products are aligned this should absolutely be considered an EAP or an op-in beta.
Then you can go GA once all products are aligned.

As it presented now it'll just make an already bad situation worse.

[Jared Schmitt]

@Alex Chiu 

You mentioned

The goal is to first prove the customer benefits of the seasonal release approach with Jira, and then extend it to other Atlassian products over time.

You add complexity, which makes user experience worse. And you expect this worsening complexity prove the complexity was beneficial? How?

Could you roll it out to all Jira products at least? Then you have a chance to gather the data you're looking for. Don't get me wrong: I like the idea of seasonal releases; just as it is often the case with Atlassian PM: It doesn't make sense in the real worlds.