RFC-131: Forge Release Tracks

General Request for Comments (RFC)
1

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Project Summary

This project is a proposal to extend Jira’s https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Coming-soon-Jira-seasonal-releases/ba-p/3177320 to Forge apps, giving Cloud admins predictability over when user-visible changes in Forge apps reach their sites. Admins will be able to manage delivery to lower environments (e.g., Preview/sandboxes) but cannot defer production updates beyond the seasonal release window. Developers would gate new user-visible features behind feature flags, and those features would roll out on a predictable seasonal cadence (Spring, Summer, Autumn), flowing through Continuous → Preview → Bundled tracks with built-in testing windows for Premium and Enterprise customers.

This RFC builds on the direction established by https://community.developer.atlassian.com/t/rfc-106-future-of-forge-versioning-permissions/94323, which decouples app code versions from permission consent. With permissions decoupled and code updates flowing automatically, release tracks become the natural next layer of admin control: governing feature visibility rather than code deployment.

  • Publish: 17 April 2026

  • Discuss: 8 May 2026

  • Resolve: 22 May 2026

Problem

RFC-106 moves Forge app code updates to automatic rollout for all customers. This improves delivery efficiency, but there remains an admin-facing gap: limited control and predictability over when user-visible changes appear on their sites.

Jira Cloud addressed this same problem with:

Today, Forge apps are not part of this model and large/complex Enterprise customers struggle to coordinate their testing workflows across different kinds of changes.

The Future of Forge Release Tracks

We envision a model where Forge apps participate naturally in the same seasonal rhythm as Atlassian’s first-party products. Here’s what it would look like:

  • Seasonal cadence, aligned with Jira: Three release moments per year (Spring, Summer, Autumn). User-visible features concentrate in these windows, giving admins a single calendar to plan around.

  • Feature visibility, not deployment control: Like Jira’s release tracks, this controls when features appear to users, not when code is deployed. Developers continue to deploy continuously and feature flags govern visibility.

  • Admin control via familiar UI: The existing Release Tracks page in Admin Hub extends to include Forge apps. Admins choose Continuous, Preview, or Bundled per app (or set a site-wide default).

  • Developer opt-in (initially): Participation is opt-in. Apps that don’t participate continue to roll out changes immediately, as they do today.

Taking an iterative approach

We recognise that this is a significant investment on top of the versioning changes already underway with Rolling Releases. We will adopt an iterative approach:

  1. First: Complete the https://community.developer.atlassian.com/t/rfc-106-future-of-forge-versioning-permissions/94323 work (decouple versions from permissions, runtime permission checks, rolling code updates).

  2. Then: Layer release track support on top, starting with an opt-in model for developers and Admin Hub integration for Premium and Enterprise customers.

  3. Later: Based on feedback, drive broader adoption (e.g. making release tracks the default for new Forge apps).

Proposed Solution

Seasonal Release Cadence

Forge apps that opt in would follow the same three-season cadence as Jira:

Season Continuous Track Preview Track (Sandbox) Bundled Track (Production)
Spring (aligned to TEAM) Late April Early May Early June
Summer Late July Early August Early September
Autumn (aligned to TEAM Europe) October November December

Between seasonal releases, only bug fixes, security patches, and non-user-visible changes would roll out. This mirrors the Jira model where monthly bundles still exist, but significant user-visible changes concentrate in the three seasonal windows.

Developer Experience

Opting In

A Forge app developer opts in via the Developer Console by enabling release tracks for feature flags for their Jira app.

Developer Console → Feature flags → Release tracks (illustrative)
{
  "releaseTracks": {
    "enabled": true,
    "defaultTargetSeason": "summer-26",
    "userVisibleRequiresTargetSeason": true
  }
}

Developing a Feature

  1. Build the feature and deploy it behind a Forge feature flag (using the existing @forge/feature-flags API).

  2. Tag the flag with a changeCategory: a metadata field that captures the level/type of end‑user impact.
    Note: Category names and examples are illustrative and not final. We’re seeking feedback on what works best.

Category Impact Examples Suggested handling
breaking Affects all customers very hard/costly to roll back Migrate major app UI to Custom UI Must target a seasonal release
major-workflow Impacts most customers, reversible but high cost/risk New scopes model app-wide settings overhaul Must target a seasonal release
conceptual Affects some customers, easier to reverse New issue panel or admin page Can target seasonal or continuous depending on risk
low-impact Minor, low-risk change Minor UI polish Continuous
internal Tiny surface area, no customer-visible impact Refactor function Continuous

Feature flag usage (non-final, illustrative only)

import { checkFeatureFlag } from '@forge/feature-flags';
const showNewDashboard = await checkFeatureFlag('new-dashboard', {
  changeCategory: 'low-impact', 
  targetSeason: 'summer-26',
});
if (showNewDashboard) {
  // Render new dashboard
} else {
  // Render existing dashboard
}

Release-day flag flipping

No manual flip will be required on release day. Developers set the flag metadata once (changeCategory + targetSeason), and the platform automatically makes the flag eligible and visible per the site’s track schedule (Continuous, Preview, Bundled). This keeps Forge aligned with Atlassian’s internal release track orchestration. We expect an emergency override/kill‑switch to exist, and the final Developer Console UX is still TBD.

Rollout Sequence (non-final, illustrative only)

Developer deploys code (all sites, feature hidden)
         │
         ▼
Seasonal release window opens
         │
         ├──► Continuous track sites: feature becomes visible immediately
         │
         ├──► Preview track sandboxes: feature becomes visible (~30 days before Bundled)
         │
         └──► Bundled track production: feature becomes visible in the next monthly bundle

How It Works: Admin Experience

The existing Release Tracks page in Admin Hub (admin.atlassian.com) would be extended to include a Forge apps section. Admins would see:

  • A list of installed Forge apps that support release tracks

  • The ability to set a track preference per app (Continuous, Preview, Bundled) or use a site-wide default

  • An “Upcoming app changes” view showing what’s coming in the next seasonal release for each app

Admin Action Result
Set app to Continuous New features appear as soon as the seasonal release window opens
Set app to Preview (sandbox) New features appear in sandbox ~30 days before Bundled production rollout
Set app to Bundled (production) New features appear in the seasonal Bundled release

Interaction with Rolling Releases Permission Changes

Rolling Releases decouples permissions from code versions, meaning code updates roll out automatically while permission changes wait for admin consent. Release tracks add a second layer of control on top:

Change Type Governed by Rolling Releases Governed by Release Tracks Admin Experience
Bug fix / security patch (no new permissions, no UX change) Rolls out automatically Not gated - ships immediately Transparent, no action needed
New feature (no new permissions) Rolls out automatically Gated by release track Feature appears per track schedule
New feature + new permissions Rolls out automatically but permissions require consent Gated by release track Feature activates per track schedule
Permission-only change (no UX change) Permissions require consent Not gated Admin approves at convenience

To support this, we propose a pre-consent flow: during the Preview window, Admin Hub surfaces upcoming permission changes alongside the feature description. Admins can approve new scopes in advance so the feature activates seamlessly when the Bundled release window opens.

Surface release track context to apps at runtime

Building on the runtime permissions APIs, we would expand the @forge/api surface to expose the site’s release track preference

import { releaseTrack } from '@forge/api';
const trackInfo = await releaseTrack.getSiteContext();
if (trackInfo.track == 'bundled') {
  // Show “coming soon” messaging, link to admin help, etc.
} else {
  // Continuous/preview sites may see features earlier
}

This enables developers to show contextual messaging (e.g. “This feature is coming in Summer '26”) or to plan progressive rollouts within their own analytics.

Asks

We appreciate your engagement and look for feedback on this RFC that will help shape this offering.

Specifically, we would love to get some insights on:

  1. Would seasonal cadence work for your apps? Three release moments per year aligns with Jira’s model, but is that too infrequent for the pace of your app’s development? Would you prefer more frequent windows?

  2. What happens when a developer ships a user-visible change without a feature flag? If a Forge app opts into release tracks but deploys a change without gating it behind a flag, should the platform block the deployment? Warn the developer? Allow it through?

  3. Granularity of admin control: Should admins set a release track per-app, or per-site for all Forge apps? Per-app is more flexible but could create sprawl.

  4. Interaction with Rolling Releases opt-in: Should release track opt-in require rolling releases opt-in as a prerequisite, or should they be independent? We believe they are complementary https://community.developer.atlassian.com/t/rfc-106-future-of-forge-versioning-permissions/94323 handles permissions, release tracks handle feature visibility, but would like your perspective.

  5. Pre-consent for permissions: During the Preview window, we’d surface upcoming permission changes for admins to approve in advance. Should admins be able to bulk-approve all seasonal permission changes?

  6. Marketplace review alignment: Should Marketplace review timelines be aligned with the seasonal cadence so approved versions are ready for the next release window?

  7. What tools or features would help you adopt this model? What support can Atlassian provide to make the transition to feature-flag-gated development practical for your team?

2

Modern cloud app development should always have continuous releases. Modern software companies are pushing new releases to production multiple times per day. This is standard software development practice in the 21st century.

If you’re deploying feature or workflow changes it’s far better UX practice to incrementally make those changes in continuous releases rather than via a bulk user-disorienting change every four months.

Additionally the more complexity you add to the update/versioning/release model for Forge apps, the more you are worsening the fundamental problem: most admins do not take manual action.

3

I think there are much more pressing issues that need to be addressed than this in forge. I’d prefer resources be applied to the large number of connect feature non-parities.

4

I can definitvley see the need for this in large organizations/enterprises where training/support is on a small team.

Only reservation I have is that we’re limited to 10 feature flags today in Forge. We’d need a lot more if we’re going to be supporting Quarterly releases.

Also - would the apps be bundled into the bundled release notes that Atlassian sends out? (That would be really appetizing).

Finally - in order to really support this from a vendor perspective - we’d need analytics and apis. Partially so that we can plan our messaging to customers (ie it doesn’t make sense telling a user in the app - hey check this out if they’re not going to get the feature for another 2 months) and so that we can see if anyone is on the Bundled Track etc.

Hope that makes sense.

5

Vendors: Please fix presseing issues like Connect to Forge feature parity, app versioning and so on.

Atlassian: Hey vendors, here is yet another feature nobody asked for.

I am sorry but I am so burnt out by Connect to Forge migration, I do not have any feedback other than rage!

6

For clarity, I would encourage Atlassian to consider specific Release flags instead of intertwining this with feature flags.

Once a release target season has passed, the code can be cleaned up and conditional statements can be removed. This will allow us to differentiate between the normal feature flag usage and features that are specific to a release cadence.

7

As a concept I can see how this would work, but once again only focuses on fully Forge apps.

Forge feature flags are not available from the Remote, so the release gate changes only get applied to Forge modules. Any non runs-on-atlassian app that utilises an external remote would be unable to create conditional logic based on feature flags without trusting user supplied data in the request to the remote.

This RFC relies on RFC-106, which still forces vendors to have to wrap all new behaviour within permission checks (and without rolling release EAP, check the Forge version and compare with permissions for that given version). Changing this behaviour to use release gate feature flags adds another layer of complexity, where the installed app now needs to have the right ‘version’ or permissions, then also needs the right release gate feature flags enabled.

As others have mentioned, existing limits with Forge feature flags are also insufficient. This just feels like another hoop vendors jump through without solving the root problem, and without parity with connect, all of these permission/flag checks will still fallback to us performing connect functionality to avoid breaking changes.

8

Hi. I appreciate the intent behind this RFC, but I think it’s a technical solution to a communication problem. We already use feature flags. We already control when features become visible to users. If I knew the dates of Jira and Confluence’s seasonal releases, I could align my feature releases to them today. No platform changes needed. The fact that I, an active Forge app vendor, didn’t know Jira had moved to three seasonal releases until reading this RFC probably says more about the real gap than any technical solution can address. Has Confluence done the same?

As Denny says, there’s also a practical gap, since this proposal appears to assume Forge-hosted execution, and we use Forge Remote in most of our apps. This reinforces my broader point: the simpler approach is to give us the context (getSiteContext, the seasonal calendar) and let us manage our own feature visibility. This will work regardless of hosting model.

What I actually need from Atlassian to align with a seasonal cadence:

  1. share the parent product roadmap so I can plan features against it

  2. publish the seasonal calendar prominently to developers

  3. tell us and commit to which parent release that platform APIs are targeting so I can build accordingly

Right now, Atlassian’s own developer platform changes (monetisation, Forge migration, deprecations) ship continuously throughout the year and demand immediate response from vendors, regardless of any seasonal rhythm.

I’d also gently suggest that before layering release track infrastructure on top of Forge, the priority should be platform stability. I have documented Forge issues that remain unresolved. I haven’t got Enterprise customers asking for feature flag orchestration, but they are asking for confidence that Forge works. The sequencing should be:

  • fix Forge

  • improve communication with app vendors

  • then build release coordination tooling

If Atlassian wants one step that would get most of the way there: ship the proposed getSiteContext API, publish the seasonal calendar, and trust app vendors to align. We will, if we know when.

9

I agree with the other commenters about this change adding complexity to an already-complex scenario. It would be great if, instead of just continually laying on additional layers of complexity, there could also perhaps be some efforts to reduce existing complexity at the same time as adding it.

Also as stated above, Atlassian needs better inducements for admins to actually update major versions, including permissions, beyond the rolling releases feature. For example, one way to do this could be to automatically opt-in instances to app permission updates after an ‘X’ day cooling off window (during which time the permission changes are surfaced in a visible place, admins are alerted, and admins can override the choice within the cooling off period, pin versions, or whatever). You could also allow sites or organizations to completely disable the auto-opt-in feature if they want.

Atlassian seems comfortable ramming AI data sharing down everyone’s throats as an opt-in default, so why not this?

If we cannot at least have the majority of customers working with the most recent code, and we are instead throwing feature flags on top of release tracks on top of disjointed permissions, it becomes a nightmare to manage for app vendors.

For the use of feature flags, in addition to the gap highlighted in earlier comments about missing Forge Remote support, the other major issue is that the existing feature flags API is effectively limited to front end tweaks. It cannot be used in the equivalent of display conditions in the manifest, meaning there is no way to selectively enable or disable modules based on feature flag status. Especially when trying to build major features, this capability is a hard prerequisite, since the majority of Forge modules are user-visible.

10

fyi Atlassian for every RFC you can simply dump in the link to your AI tool of choice, get a summary of partner responses and better solution ideas, eg: https://claude.ai/share/92add9ed-52f4-4d9f-802b-85d75c71280a

Should ideally be a default embedded practice for every CDAC thread.

11

To reinforce what several have said above, the complexity of the current forge versioning ecosystem is already a significant problem. Splitting code and permissions is adding further complexity. This proposal makes an already serious problem worse by creating an untestable cross-product with thousands of combinations of manifests, code, permissions and feature flags.

However, there is an option to make a significantly positive impact on customer satisfaction and marketplace app stability. Proposal is to use the Seasonal Release as the mandatory upgrade timing point for all forge app major versions. i.e. All active installs get the latest app changes the same way they get the latest Jira, Confluence changes, 3 times a year.

The new release track infrastructure described in the RFC makes this possible because it will have the route to communicate to site admins about installed apps’ upcoming permission changes. Those that actually care can review them in advance and opt out (by uninstalling the app) before the season upgrade date.

Having customers only 3 months behind on major versions is far more manageable then the situation today where apps are marooned years behind. The reduced test surface area (fewer live versions) and improved quality and security alone justifies this change.

12

There would have to be very detailed descriptions of what constitutes a “user-visible change”. Your example of “Migrate major app UI to Custom UI” already confused me - why would that be considered a “breaking” change, if the migration from Forge UI to Custom UI is functionally equivalent? OTOH I would consider “New issue panel or admin page” a major change, which was just labeled as conceptual in the RFC and wouldn’t require using release tracks. How is that not a “user-visible change”? I’m confused.

13

This will vary by app maturity. For a freshly launched app, I would expect much more frequent windows. New apps need to be able to iterate much more quickly than three times per year. Even if they are potentially big changes.

It is much more appealing to tie into the monthly change tracks (with sandbox evaluations) than to the seasonal change tracks.

Whatever you decide here, please do not make it impossible to deploy a change based on some blocking algorithm or AI-controlled decision gate. If Atlassian decides to block by default, then please provide a vendor override that doesn’t require a support ticket.

Overall opinion:

  1. This seems like a nice feature that could provide a valuable competitive advantage to mature apps marketing to large customers. (Which is a good thing.) And this would be especially valuable to change-sensitive customers using Government Cloud or Isolated Cloud.
  2. That said, please ensure this is only available as a competitive advantage for the vendors/apps that seek to use it. Please DO NOT make seasonal release tracks compulsory. (Opt-out instead of opt-in is fine, as long as opting out is possible.) I work with a lot of regulated companies that will prefer apps to use this feature. But even in highly regulated environments, not all apps carry the same risk profile, which means not every app needs to follow the same change rules.
  3. Please save this for 2028. I’m unsure if I want to :sob: or :face_vomiting: that Atlassian is thinking about this kind of change while there are still migration blockers from Connect to Forge.
14

As others have already said, at the moment we have much bigger concerns than this and would prefer to see Atlassian’s efforts going into improving Forge platform foundations so we can build with confidence. Lack of stability and consistency, lack of Connect parity, subpar performance, and often outdated documentation are some of the basic issues we struggle with regularly.

I am sure this RFC is driven by customer demand, but I do not think it will achieve the underlying goal of better stability with predictable feature rollouts if there are fundamental platform gaps. It will just delay the issues from appearing during the rollout window.

Apologies for not actually commenting on the RFC questions.

15

1st, I think Atlassian should work on this release-tracking feature to provide the real value that is currently missing. It does not work for your own apps, and you want to put effort into having marketplace apps do it.
There are plenty of examples in the user community stating that the information from release track/app updates is not real, the source of information is many - i.e., community posts, that are not in the public change blog or the app updates; updates that don’t show any preview on sandboxes when bundled; the feature showing rollout complete, when its not implemented in the site yet; features mentioned on the release app update, but not on public change blog; another new tool to show the seasonal releases that are not inclued on the public blog nor in the app update/release track.

An example is Jira

Im doing my own release track - trying to get information from both sides, add info from community.

Not to mention the changelog for APIs or development stuff that are not connected in any of this.

Forge has its own JPD roadmap now. JPD has its own roadmap.

So there is a lot you can do to fix your own release track features and communication.

16

Hi all, thank you for all the feedback on this RFC, it has pushed us to reframe the proposal in a few important ways. I want to address the recurring themes in one place rather than fragmenting the discussion across replies, so here’s where we’ve landed after digesting everything.

First, an important clarification: seasonal releases reflect Atlassian’s broader move toward a more predictable cadence for major user-visible changes. Jira is one of the first products adopting three seasonal release moments per year, and other products may adopt a similar rhythm over time.

The intention of RFC‑131 is to help Forge apps participate in the same seasonal rhythm, so admins get a coherent, predictable change story across Jira and apps. Rather than changing how apps deploy, this is about giving partners an optional way to align user‑visible app updates with seasonal moments where that makes sense.

What counts as user-impacting

For this proposal, the seasonal cadence should focus on major user-visible changes that admins or customers would reasonably want advance notice of. Bug fixes, security fixes, operational improvements, and minor feature iterations should continue to ship continuously unless they materially change the end-user or admin experience.

Platform readiness comes first

A strong theme is: don’t add release‑track complexity before fixing core platform issues and migration blockers.

Before we ask anyone to align to seasonal cadence, we plan to:

  • GA rolling releases and the new versioning model
  • Raise feature flag limits and make them work consistently (Forge hosted + Remote, module/manifest level)
  • Improve our own release communications so Jira’s seasonal model is clear to partners

That’s effectively Phase 0: get the foundations in place and reduce existing pain before adding anything new.

Opt‑in to Seasonal releases

We’ve also heard concern that this could become compulsory or gate your ability to ship. In the proposed design:

  • Participation is opt‑in. If you don’t opt in, you keep shipping exactly as you do today.
  • We’re not blocking deployments. The mechanism is incentive‑based: if you provide seasonal‑aligned, user‑impacting notes on time, we can surface your changes alongside Jira’s seasonal marketing communications. If you don’t, you’re simply not included there.
  • Continuous deployment remains the default. The focus is on foundations, communication, and optional seasonal participation. Release tracks may become relevant later for governing when users see changes, not when you can deploy. You can still deploy as often as you like and use flags/versions to control visibility.

Start with communication

Several of you called out that the core problem is communication, not a lack of orchestration. We agree, and that’s what Phase 1 to focus on:

  • Sharing Jira’s own seasonal themes/roadmaps so partners can plan work that makes sense alongside them
  • Trust partners to use feature flags, versions, or their own mechanisms to align user‑visible changes where it’s appropriate

Only after we’ve learned from this lighter‑weight model would we consider any heavier orchestration (and only if admins and vendors both see clear value).