Atlassian continues to ignore this existential risk and here’s yet another example: any migrating/existing app that adds storage:app will now trigger a major version and there’s absolutely nothing you can do about it.
Exactly as I’ve warned for years: all it takes is one forced major version like Atlassian has done here and you get zombie apps with 70-90% of installs permanently stuck on outdated versions.
ADMINS DO NOT MANUALLY UPDATE APPS!!!
Outdated apps = low usage = subscriptions cancelled.
Even the wording of this changelog is completely clueless to this fact: https://developer.atlassian.com/platform/forge/changelog/#CHANGE-3206
“Expect site admins to approve the new version”… they won’t!
“Consider how you will support customers who remain on the previous version until they approve the upgrade”… they will never approve the upgrade!
Revenue penalties are in effect and migration deadlines are set when this is the immature state of the platform.
I can confirm this. Even I myself find it very confusing where to upgrade my app in my production test environment. The whole Marketplace App Management is so deeply hidden and confusing.
If you force this that admins have to update and approve then please at least let the admins get a notification like : „new version of app 123 available, please update and approve to ensure the app works properly and is up to date due to security …"
I have had this case myself and no one after 2 months has updated to the latest major version.
Our whole migration to Forge was built on that scope not being a major upgrade.
Also nice to let everybody know it ON TIME!!!
They made the change on April 30 and added the changelog entry on 5th May 
Most likely because someone reported it. It’s a feature, not a bug now. Forget about informing vendors in advance or providing reasoning for this change.
Why is this platform such a shitshow? How are such actions normalized?
Hi everyone,
Thanks for raising this. We understand the frustration and the impact of this change on your apps and your business.
To be clear, we are treating this as a bug, not the intended end state. This may not have come across clearly in the changelog. We are actively working on restoring storage:app as a scope change that can be managed through bulk upgrade, removing the need for individual site admin approval. We will provide an update on this thread and this bug ticket with fix timelines as soon as we can.
Looking further ahead, we’re building Rolling Releases, which will fundamentally change how Forge versioning works. With Rolling Releases, code updates are decoupled from permission changes. This means your latest code ships to all installations without admins pressing update, while new permissions are handled gracefully at runtime using our Permissions SDK. This eliminates the “zombie app” problem where installs get stuck on outdated versions. Once Rolling Releases is fully live, the manual bulk upgrade command will no longer be needed. When you deploy, upgrades roll out automatically as part of the release. Rolling Releases is currently in EAP, and storage:app transitions are not yet supported. Bringing storage:app into scope is a priority for the next milestone, so that adding storage to your app will no longer create version fragmentation at all.
Thank you.
Nah it won’t mate. Rolling Releases is directionally good but it merely shifts the required manual admin action from approving an upgrade to approving permission scopes.
The core problem is that admins don’t take these manual actions, and Atlassian has put zero effort into a notification system to encourage admins to take action.
Nor is there any plan whatsoever from Atlassian to fix all the Forge apps that are already in this zombie state. Can they be fixed retroactively without manual admin action? If not, what are partners supposed to do?
Unforgivably infuriating that revenue penalties are already in effect and EOY migration deadlines are set whilst the fundamentals of versioning on Forge are still in flux.
Yeah, it might not have. Perhaps the “bug report” format threw everyone off:
[ANNOUNCEMENT]…We’ve updated Forge app upgrade behaviour
But seriously, thank you for submitting a real bug report. Are there any plans to update the change log with a link back to the bug ID?
Atlassian can easily solve this problem by sending a notification to the administrators and prompt them to upgrade to the latest version.
Taken at face value:
- Prior to April 30,
storage:app could be rolled out using bulk upgrade
- A change was made, which Atlassian confirms is being treated “as a bug”
- The changelog entry mentions "Atlassian is actively investigating restoring
storage:app as a scope increase that is able to be managed by bulk upgrade
- ECO-1493 mentions similar
I may be misunderstanding or underestimating the restoration work required, but isn’t this just reversing the April 30 change?
I don’t understand why ECO-1493 created 5 days ago is still in “Needs Triage” status.
You’ve indicated that this was an unintentional change to something that previously worked. What “active investigation” is needed? Presumably you know the cause and you know the previous state you want to get back to.
Here’s why this matters to us:
- We enjoyed the benefit of the prior-April 30 behaviour to bulk upgrade one of our apps
- However, as we’ve noted previously, running
bulk upgrade often leaves a number of installations as “failed”. In the case of this app, we have approximately 30 installs that failed to be upgraded successfully.
- Of those 30 failed installs, we still see traffic from some to our old Connect infrastructure, meaning that we’re left maintaining this infrastructure (at a cost) for these stragglers.
- When we try to re-run the bulk upgrade again for these installations, we now get “No upgrade paths available”, presumably due to
storage:app now no longer being eligible
So we’re now in this limbo state where most of our installations were upgraded with storage:app, but for the remainder we’re waiting for ECO-1493 to be resolved.
If we’re to believe that this was genuinely a bug that wasn’t supposed to change previous behaviour, surely that should have been fixed by now.
Hi everyone, quick update.
The issue has now been resolved.
Thanks.