Thanks for sharing the RFC. However, I think it is too complicated to be useful and is from my perspective setting the wrong focus in regard to the underlying problem. It also overlaps with the optional scopes topic ( Feedback requested: Optional Scopes in Forge ), as pointed out by @marc. Actually, the described idea is a technical solution for optional scopes. But scope changes which currently lead to major new versions are not necessarily optional. So for example if another endpoint of the Confluence V1 API is replaced with one of the V2 API, another scope has to be added since the V2 API is using the granular scopes. Such a change is definitely not optional because the app will just stop working after the deprecation period of the endpoint. The RFC is missing this aspect.
Regarding the Asks
What use-cases for your apps that this offering would enable?
As described above, only for changes that are really optional. But I would be really hesitant to use it because the maintenance overhead would be too high if there are several scope related switches in the code (testing different code branches with certain scopes enabled/disabled). Handling support cases would also become much more complicated as already mentioned by others, especially if you compare it with the current situation where you just need to know the app’s version the customer is on.
Of course there is the possibility to use this feature in a way that disables the app completely until the scopes are approved so that you don’t have to hassle with multiple switches. But from customer perspective that’s a terrible approach as it leads to a disruptive experience which can’t be solved by the actual users of the app (imagine the admin being on a 3 week vacation).
With all that in mind I prefer the current state over the suggested solution. There is no need to support an old version forever. Developers can for example add a banner or whatever in an older major version which informs the customer that this version is deprecated and will stop working in X days, if they don’t update. After X days, the frontend features of the app could be reduced to a message that the version is not supported anymore. Well, I have to admit that I never had this use case as some blockers prevent the migration to Forge, so I can’t tell if it’s easy to implement or not. But if it is too complicated maybe it would make more sense to simplify this instead of investing in the optional scopes approach.
Regarding the other Asks: not applicable as the suggested idea is not really useful.
Alternatives and different focus:
- Automatic updates as described in other comments. There are also some interesting suggestions to give admins more control (RFC-106: Future of Forge versioning - Permissions - #39 by scott.dudley).
- If automatic updates are not possible, keep the current solution and add some tools to simplify marking old major versions deprecated/unsupported if needed (e.g. some Forge CLI or Marketplace API to mark versions as deprecated or unsupported with a custom message and some Forge functionality to check for it similar to a license verification).
- Improve how admins can be made aware that they have to approve a new app version. Also consider that a “please inform your admin” message in an app is often not that helpful, as normal app users typically don’t know who’s an admin.