Are what is in the release notes really there?

[#1]

Hello all,

We migrated to the cloud this past February and as newbies we are learning about this new world. One of the things that we’ve started exploring is how to do change management for the monthly releases that impact our users (thank you @Patrice Champet for this excellent post!) and in digging into what is in the release notes, we’ve been quite surprised & puzzled and are wondering what the community’s take is.

For example, in looking at the 'release tracks' for our production Jira, 'last release' April 14, 2026 there is this list of changes for this specific date yet some of them are not visible:

1. "Deleting work type schemes REST API: Change in behavior" has a status of "coming soon" and a "rollout schedule” of "No timeframe yet".
2. "Proactive AI incident summaries in Slack channels" says "Jira Service Management ChatOps now proactively sends an AI-generated incident summary..." There is no mention of Jira anywhere yet Jira is listed as an "App impacted".
3. "Improved filters in List view" has a status of "Rollout Complete" yet none of these new tabs ('Basic', 'Advanced', 'JQL') are visible as filter options. This is not only true of production but also of our sandbox. so how is 'rollout complete'?

According to support

1. Deleting work type schemes REST API (Coming Soon)
   Release tracks often list items that are part of the April 14 code update, even if the feature isn't "flipped on" for everyone yet.
   1. Why it’s in the notes: We include the backend code in the bundle so the system is ready.
   2. Why there's no timeframe: This is a progressive rollout. The code is there, but we enable the actual feature in stages to make sure everything stays stable.
2. Proactive AI incident summaries and Jira Impact
   You noticed Jira is listed as an "impacted app" even though the focus is on Jira Service Management (JSM).
   1. The Connection: Jira is flagged because the ChatOps bot acts as a bridge. To create those AI summaries, the bot has to read and process data directly from your Jira issues.
   2. Why it matters: Since the tool interacts with your Jira data to summarize work, we categorize the core Jira app as "impacted."
3. Improved filters in List view
   While the release notes say "Complete," this refers to the global code deployment. We are currently rolling the actual interface changes out in stages.
   1. The Status: Your site is currently in a group that is scheduled to receive the update shortly.
   2. What this means: To ensure performance and stability, we enable the new UI for groups of customers at a time. This helps our engineers monitor the impact and make sure the new filters work perfectly for everyone.
   3. When will you see it? As we move to the final stage of the launch, your site will update automatically. You’ll see the 'Basic', 'Advanced', and 'JQL' tabs soon without needing to change any settings.

The Connection: Jira is flagged because the ChatOps bot acts as a bridge. To create those AI summaries, the bot has to read and process data directly from your Jira issues.

Okay, that again makes sense from an Atlassian perspective but why does this 'under the covers' code/functionality matter to me?

For us, this is the heart of the issue:

Release tracks often list items that are part of the April 14 code update, even if the feature isn't "flipped on" for everyone yet.

From an end-user perspective, if I don't see the enhancement/fix/have the functionality, it does NOT exist. It is not "released". I can see from an Atlassian perspective that the code is released but these release notes are for us, the end users. With that perspective in mind, these 3 examples are not just noise, but red-herrings and in the case of the REST API & List filtering, we will have to periodically check (& re-check?) to see if they are on and then need to do an ad-hoc communication to our users.

For us we would like to have Atlassian revisit the release notes through the lens of the end-users, the release notes audience as the current content is not trustworthy for us as we consider communication & potential training for our user base. Additionally, the current inaccurate content is causing more work for us to validate & watch for, these changes to be implemented in our environments. Kudos to support though for creating this suggestion Standardize Cloud Release Track status definitions to reflect actual feature availability for end-users, which if you find value in it, please add your voice & vote!

But is this just us? What of you?

[Alex Hall]

I constantly struggle with the challenges of reviewing release notes. I review every single one in our release tracks. Many of them don't affect the way we work, so I don't look at them. Others will affect us, so I try to see what they look like in our sandbox (which has a continuous release track). Oftentimes I simply don't see any evidenced change there. Sometimes I do.

Some changes have big impact on us, and I keep a to-do list to constantly check to see if the feature is live because I need to address it immediately. In one instance, I did this for about 45 days before it showed up in our production environment, well behind predicted schedule. 

I worry the only way to get meaningful attention to this ambiguity and lack of predictability is to start a support ticket every time there lacks evidence of a 'rollout complete' feature. Maybe with enough volume Atlassian would be motivated to improve this experience. But maybe not, and then I'd just be annoying support staff who don't have any ability to affect change. 

[Darryl Lee]

Hey @chris sieverts - in answer to your question, I've pretty much resigned myself to the answer that Features rollout whenever Atlassian gets around to it.

Despite the promise that features in Bundled Track would start rolling single day (roughly), it's become clear that Atlassian's internal processes just can't handle that. Yeah yeah, shards, global regions, Cloud, blah blah blah. It's hard. I get it. But also, we pay you a lot of money to do the hard things.

Oh here's the official docs:

To get most of the changes as a group on a monthly cadence. Bundled changes roll out from 22:00 UTC on the second Tuesday of each month. You can’t customize the time your apps receive changes.

"most of"

"changes rollout from 22:00 UTC"

Yeah that's a lot of weasely/wiggley language there.

---

Thanks for reminding me of @Patrice Champet's hard work - it is incredibly impressive.

But it also seems like SO MUCH WORK that honestly I do not have time for. I too run a monthly review of new features with anyone at the company who wants to join. (It's usually me at like 2 other people.)

But writing a blog? Putting them into a database? Man, that's a LOT.

I did start publicly sharing my "reformatted" Release Notes here: https://releasetracks.atlassian.net/wiki/spaces/RT/overview

I'm already doing it for work, so I can copy and paste it there. Or vice-versa. Hopefully it helps.

---

To your point about the this feature:

The Connection: Jira is flagged because the ChatOps bot acts as a bridge. To create those AI summaries, the bot has to read and process data directly from your Jira issues.

Okay, that again makes sense from an Atlassian perspective but why does this 'under the covers' code/functionality matter to me?

OMG yeah. Some really really weird stuff ends up in Release Notes. Like this one:

Global background script module for Jira Forge apps
Forge platform developers and Marketplace Partners can now build apps that run global background scripts in Jira Cloud. This new capability doesn't introduce changes to existing settings or interfaces, but it enables more powerful behind-the-scenes automation, such as sending alerts to all users who need to complete compliance training.

To learn more, see Jira global background script (Preview).

I mean, in contrast to many other features, at least this one has a LINK do more documentation. But it is so weird that it is in the Jira release notes, which ostensibly would cover things that Users or Admins would see. (Eventually. Hopefully.)

---

One last thing. I saw this session advertised at the upcoming Team 26 conference and it cracks me up that they're going to demo creating a Rovo Agent to create a Better Release Note Review Process™ 

https://events.atlassian.com/team/sessions?Id=3971620

It makes me laugh because it's basically conceding that weekly Cloud Documentation blog posts are so poorly organized that they require an AI agent to manage them.

I will be asking how they plan to avoid duplicates, since the weekly notes OFTEN repeat features every week as the rollout schedules there are even more opaque than they are for Bundled Releases.

@Jens Schumacher - Released_so has had to figure this out for his unofficial changelog for Atlassian Cloud.

(Spoiler: 

If you scrape the HTML of the Cloud Documentation blog, the <h4> tag for each feature has an ID like:
AtlassianCloudchangesApr6toApr13,2026-MobileSecurity:ToggleAppTrustforIntuneMAMpoliciesFD-183139

That FD-183139 is apparently the issue key for that feature, and seems to be consistent with what is in the underlying feeds/API calls behind Platform Experiences -> App updates / Release tracks that you can find in the admin.atlassian.com hub.)

[Haddon Fisher]

+1 to Darryl Lee's comment - I pretty much gave up reading these for any other reason than "what should I (generally) expect to see in my instance at some point in the next six months". In some cases what you read about does show up as advertised...but I have also seen things change shape before it hits our instance, or just never materialize at all.

To be honest, I have never been able to wrap my head around why Atlassian has such a problem with this at all, let alone something that they haven't been able to improve on in at least a decade.

I really think Atlassian has to bite the bullet, accept that they aren't a start-up anymore, and adopt some kind of work management tool to help them track all of their dependencies and releases. Anyone have a recommendation?

[Darryl Lee]

@Haddon Fisher writes

To be honest, I have never been able to wrap my head around why Atlassian has such a problem with this at all, let alone something that they haven't been able to improve on in at least a decade.

I really think Atlassian has to bite the bullet, accept that they aren't a start-up anymore, and adopt some kind of work management tool to help them track all of their dependencies and releases. Anyone have a recommendation?

Heh.

So, the funny thing is that before Cloud (and what must be a constant grind of continuous releases and also probably lots of internal pressure to make sure new features drive revenue and increase shareholder value), Atlassian the "start-up" got really really damned good at Release Notes:

https://confluence.atlassian.com/jirasoftware/jira-software-11-3-x-release-notes-1689288832.html

I mean, look at how nicely organized this is!

Highlights

• End-of-life policy
• What's changed since the last LTS release
  • Top features
  • Critical bug fixes

Gosh, the Cloud is so hard. It must be really challenging adapting a release workflow for a self-hosted product into something that needs to be more Agile. I mean let's be fair, it was only back in 2011 when JIRA OnDemand came out.

I mean what, are they supposed to fix/adapt that workflow for continuous releases in just 15 years!?

[Darryl Lee]

Amazing, they got these Release Notes for version 4.4 out on August 2, 2011, just before announcing JIRA On Demand in October 25, 2011.

Man, the crazy life of a Startup, huh?

[Becker_ Rene]

I gave up on reading any release or change announcements.

I applaud @Darryl Lee  for the patience to create a compilation.

Why did I give up though?

There are multiple sources:

• Release Track
• Cloud Updates
• E-Mails
• Community Posts
• Popups in the applications

One has to go through each one, read up and in the end, you are none the wiser because, they either do not roll out (or at some other point) or are not delivered productive ready or the description does not offer any info at all.

---

But you know what drives me mad the most? It's the changes that do not come up on either information channel. Like when they set up the new Boards (broke ~ 700 boards with us), when they change the administration of custom fields (Jira, customer field administration), introduced Teams the first time.

Not all changes are bad, but I find it annoying that they are not announced, while meaningless stuff is promoted like they invented water.

---

I agree that the "old" release information was superior in any way and it showed that they really had control over their products. Nowadays it seems like the left hand does not know what the right hand is doing. It's the effect of growing too fast for your clothing to keep up.

---

[Haddon Fisher]

Darryl Lee it's amazing - I had completely forgotten about these! It's funny what a mind will do to protect itself from the pain and suffering caused by Atlassian Cloud applications 🤣 My 2013 self is rolling in it's carefree grave, but damn, did we have it good on server.