Best Practices for Tracking Monthly Jira Cloud Releases & Understanding Beta/Optional Features

Question

Hello Jira Community,

We're trying to establish a reliable process for understanding what changes are included in our monthly Jira Cloud batch releases. Since Atlassian deploys Jira updates on the second Tuesday of each month, I'm looking for guidance on the best way to identify which features are being introduced in a given release cycle.

Currently, I've been reviewing both:

* Atlassian Cloud Blog Posts
* Atlassian Community Release Notes

Is one of these considered the authoritative source of truth for Jira Cloud releases, or is there another recommended source? Should I simply compile the previous four weeks of release notes leading up to each monthly release?

I also have a question regarding optional/configurable (Beta/Labs) features. We've been advised that features labeled "Coming Soon" in release notes often indicate functionality that will initially be available as an optional feature that admins can enable for testing.

However, when I review recent release notes, I see numerous items tagged as "Coming Soon," but when I navigate to Jira Administration → Beta Features, the list is empty.

Can someone clarify:

* How to determine which new features will be enabled automatically versus those that require administrator action?
* Whether there is a reliable way to identify upcoming Beta/Labs features before they become generally available?
* How the "Coming Soon" label relates to the Beta Features area in Jira administration?

Ultimately, we're trying to improve our ability to communicate upcoming Jira changes to our users and understand which features we can proactively test before broad rollout.

Thanks in advance for any guidance!

Melika-Everview · Answer

@James Gamble and @Gor Greyan already covered the hard part well.
release notes as the operational source of truth, the roadmap for longer-range awareness, and the "Coming Soon ≠ Beta" distinction. I won't repeat what they've nailed.

I want to pick up the last line of your question instead, because it's the part nobody's answered yet and it's the harder one: communicating upcoming changes to your own users, and knowing what's safe to test before broad rollout.

That's less an Atlassian-sources problem and more a "who on our side is actually affected" problem. A release note tells you a feature is changing; it doesn't tell you which of your teams, boards, or workflows sit in its path so the comms either go out to everyone (noise) or miss the people who'll actually feel it.

That mapping is what Everview is built for. It sits on top of Jira (Jira stays your source of record) and reads a live picture of how your teams and work actually connect, so when a change is coming you can see who it lands on before it ships, not after the tickets start looking wrong. It's the difference between announcing a change and knowing who needs the announcement.

Everview canvas — teams and work connected on one live surface, showing how a change would ripple to the teams/work in its path. Demo data, no real customer names.

The sandbox is open if you want to poke at it first (no signup) and it's on the Atlassian Marketplace if you'd rather try it on your own instance > Everview.ai

James Gamble · Answer

Hola Michael,

@Gor Greyan’s answer has the right overall direction, but there’s one important distinction I’d make first: Jira Cloud doesn’t universally deploy updates on the second Tuesday of each month. That schedule applies to the Bundled release track, which is available on Premium and Enterprise. The question currently shows Jira Cloud Free, where changes are delivered on the Continuous track as they become available rather than as a monthly bundle. Atlassian documents the release-track behavior here.

For day-to-day change management, I’d use Atlassian’s release notes rather than trying to reconstruct a monthly release from blog posts. Atlassian is consolidating Cloud release information into its newer release notes experience, which includes filtering and dedicated views for Release track changes. The Cloud roadmap is useful for longer-range planning, but it isn’t a reliable list of exactly what will reach your site in a particular release window. Atlassian’s guidance on keeping up with changes is here.

“Coming Soon” also shouldn’t be interpreted as “Beta” or “admin opt-in.” It describes rollout timing. A feature can be marked Coming Soon and then rolled out normally without ever appearing under Beta features. That explains why you can see many Coming Soon release notes while Jira Administration > System > Beta features is empty.

The Beta features page lists experimental Jira features that administrators can turn on or off. If Atlassian offers something as an Early Access Program, Beta, or other opt-in experience, the release notes or announcement should explicitly state that and include enrollment or enablement instructions. Atlassian documents the current Jira Beta feature controls here.

If proactive testing is required, the more predictable model is Premium or Enterprise, with production on the Bundled track and a sandbox on the Preview track. Atlassian’s Preview track gives the sandbox the same bundle approximately one month before production, which is much closer to a traditional change-management/test cycle than watching the Beta features page.

So I’d base your process on release notes for operational change tracking, the Cloud roadmap for longer-term awareness, and explicit Beta/EAP announcements only when Atlassian actually makes a feature available for early testing. I wouldn’t use the previous four weeks of Community posts as the definition of a monthly Jira release.

Thanks,

James

Gor Greyan · Answer

Hi @Michael Levinson

Welcome to the Atlassian Community!

For tracking upcoming changes, I would use Atlassian's Cloud release notes / What's new across Atlassian as the primary operational source rather than trying to build the monthly release from Community posts. Atlassian is actually moving the existing weekly Cloud release notes to the newer What's new across Atlassian experience, which includes rollout status, filtering, and search.

https://support.atlassian.com/organization-administration/docs/keep-up-with-changes/

The Cloud Roadmap is also useful, but for a different purpose, it gives a higher-level view of features Atlassian is planning and their expected timeframes rather than telling you exactly what has reached your Jira site.

https://www.atlassian.com/roadmap/cloud

Regarding Coming Soon and Beta Features, these shouldn't be treated as equivalent.

Coming Soon is a rollout status, not an indication that the feature is an opt-in Beta/Labs feature. A release note marked Coming Soon can represent functionality that Atlassian intends to roll out normally. Therefore, it is perfectly possible to have many Coming Soon entries in the release notes while Administration → Beta Features contains nothing.

Similarly, not every upcoming feature can be enabled early by an administrator. If Atlassian makes something available as an Early Access/Beta feature, the corresponding announcement or documentation should explicitly explain how to opt in.

If your objective is change management, I would therefore use the release notes/What's New to track what is actually rolling out, the Cloud Roadmap for longer-term planning, and Beta/EAP announcements only for features Atlassian explicitly makes available for early testing.