Rolling releases and SQL

Forge
,
1

We’re evaluating Rolling Releases (Preview) for our Forge native app. Some of our customers are currently on an older major version of our app that does not use Forge storage/SQL. In our latest major version, we introduced SQL.

In the Preview Limitations documentation, it states:

Upgrading from a version without storage to a version with storage (KVS and SQL) is not supported.

We’re trying to understand how this limitation applies to our situation.

If some customers are on a major version without SQL, and newer major versions use SQL:

  1. Does this limitation mean we cannot use Rolling Releases for the app at all while those customers remain on the older, non-SQL version?
  2. Or would Rolling Releases only apply to customers who are already on a version that includes SQL, while customers on the older non-SQL version would simply not receive those updates?
  3. More generally, does this limitation mean there is no supported upgrade path from a version without storage/SQL to a version that uses SQL, or is there another migration approach we should follow?
  4. If a customer on the older non-SQL major version manually upgrades to the newer SQL-based major version, would they then be eligible to receive subsequent Rolling Releases, or would the storage limitation still prevent that upgrade path?
  5. Will this be supported on the GA release?

Thanks!

2

Hello, glad to see you are considering rolling releases, the tl:dr is the storage/SQL limitation blocks Rolling Releases for any version transition that introduces storage, but once a customer is already on a SQL-enabled version, subsequent code-only updates can roll out normally. GA support for storage transitions is planned but not yet committed.

1. Does this limitation mean we cannot use Rolling Releases for the app at all while those customers remain on the older, non-SQL version?

Not entirely. The limitation only blocks the specific transition from a version without storage to a version with storage. Customers already on the non-SQL version simply won’t be eligible for that particular rollout, they’ll stay on their current version until they manually upgrade (as they do today). You can still use Rolling Releases for all other updates that don’t introduce storage.

2. Or would Rolling Releases only apply to customers who are already on a version that includes SQL, while customers on the older non-SQL version would simply not receive those updates?

Correct. Installations on the older non-SQL version are marked ineligible for that rollout. They remain on their current version and won’t receive the Rolling Release. Customers already on a SQL-enabled version are eligible and will receive subsequent code-only updates via Rolling Releases normally.

3. Does this limitation mean there is no supported upgrade path from a version without storage/SQL to a version that uses SQL?

There is a path, but it’s not via Rolling Releases. It requires a manual admin upgrade (the traditional major version bump flow). The admin approves the upgrade in Admin Hub, which triggers full provisioning of the SQL database for that installation. Rolling Releases doesn’t support this transition.

4. If a customer on the older non-SQL major version manually upgrades to the newer SQL-based major version, would they then be eligible to receive subsequent Rolling Releases?

Yes as above. Once a customer has manually upgraded to the SQL-enabled version (with storage provisioned), that installation is on a version that already has the storage:app scope and SQL module. Future Rolling Releases from that version onward, where no new storage is being introduced, would be eligible. The limitation only applies to the transition that adds storage, not to subsequent updates on top of it.

5. Will this be supported on the GA release?

Supporting the storage/SQL transition in Rolling Releases is a known priority, but it’s not currently committed for GA. We’ll communicate when this is on the roadmap with a timeline. In the meantime, the manual upgrade path remains the supported route for introducing storage.

3

@DeanPeach but it appears that adding SQL to a version already has storage:app mandates a major version bump too, which really makes me scratch my head. Why would swapping KVS for SQL require admin approval - provided that both are Atlassian hosted storage solutions. It’s not like Forge SQL doesn’t support data residency: https://developer.atlassian.com/platform/forge/changelog/#CHANGE-2470.

This major version bump with SQL over KVS is currently blocking our production deployment of SQL-based features. We really would like to see this bump gone.

4

Atlassian doesn’t understand the problem they think they’re solving.

Rolling Releases solves absolutely nothing. It merely shifts the core problem from manual admin updates to manual admin permission approvals.

smh