Scope changes and even scope swaps trigger major version updates for Forge apps.
These need to be manually approved. Admins refuse to do this or delay it. Multiple versions of Apps need to stick around. Nightmare for security and maintainability. – How many Jira version on the Cloud are there? Does Atlassian allow customers to simply keep running the old version of Jira because of some scope changes?
This is really bad news. Major version updates are really horrible from an app Developer perspective. Honestly you should bring this up internally at Atlassian and make all Apps update automatically. Ok customers should be informed, and they can opt out, but sticking with an outdated version of a SaaS app is against all principles in this area. Imagine your customers would be able to stick to an old version of Jira with the old navigation and the old issue view, the old Confluence editor.
I think this concept needs a review soon. Current workaround: Simple break the old version on the app and force a manual update by displaying some info for the admin. Not nice, but much better then sticking around with an old version. How do you deal with this?
4 Likes
Hi @LukasGotter,
Thanks for raising this. We understand your frustration and the challenges you face. We are taking an iterative approach to solve this, with the first milestone focusing on decoupling versions from permissions. This will address the main reasons for creating major app versions: scope, egress, and remote changes. It will reduce installations of older versions and the number of outdated major versions requiring support.
While this iteration is a positive step, it will not fully resolve app update issues, as customers will still need to approve any permission or pricing changes. Future milestones will streamline release notes and improve how permission approval requests reach admins to boost approval rates. We will also let app developers define features, each consisting of scopes and/or permissions, allowing them to specify which features are optional or mandatory.
For future milestones we are exploring how to reduce the rate of changes that require admin consent such as exploring pathways for scope changes that may not require admin consent, e.g. storage and other equivalent scope changes that may be platform-driven. We may allow customers to pre-consent to certain groups of scopes, enabling automatic rollout of changes requiring scopes from a pre-approved list. Alternatively, we may consider allowing customers to pre-consent to changes that do not cause loss of Runs on Atlassian eligibility for apps that already meet the criteria.
Cheers,
Agi
2 Likes
Hi @AngelinaIgnatova thanks for your prompt answer and pointing me to the right direction where this topic is extensively discussed. It’s a bit overwhelming to read. I’ll add my opinion there as well.
Regarding the first milestone (decoupling versions from permissions). How should that help exactly? Then you have even more versions and in addition to dealing with old versions now all versions need to deal with missing permissions.
Thanks for clarifying!
Lukas
A simple solution from my point of view would be:
- Inform admins about scope changes alongside with release notes (as you know, the release notes for Forge apps need to be fixed as well…).
- Make auto-update the default, but allow admins to schedule the update alongside/similar to release tracks.
- If they don’t update: Allow Devs to mark versions as “EOL” and Forge will then display an info automatically on all modules and in the Manage Apps sections. This would save us from shipping updates manually to these older major versions and “break” them with a similar message or continue to support them.
1 Like
After you opt in to the feature and deploy changes, all installations will update to the latest applicable version.
Yes, you will need to ensure your app handles failures gracefully for customers on outdated major versions who haven’t approved certain scopes or permissions. This is unavoidable.
Once done, you can release improvements, vulnerability patches, and other changes simultaneously to all customers instead of back-porting to previous major versions.
Note that defaulting to auto updates does not meet customer expectations. However, as mentioned, we are exploring ways to ease updates for customers who prefer their apps always up to date.
Hope this helps.
Hi @AngelinaIgnatova sounds like an improvement to me indeed! This way we can simply check for all required scopes on startup and in case force an update to continue.
Would you also be able to look into scope swaps from v1 APIs to v2 APIs? In my case we need to use the new Confluence “Spaces” V2 Endpoint. /wiki/api/v2/spaces which requires read:space:confluence - however the V1 Endpoint had scope read:confluence-space.summary – regards, Lukas