As previously announced, invocations from Forge apps that haven’t been updated since Jan 1, 2023 will now be blocked. We’re implementing this to ensure that all apps and customers continue to receive crucial fixes and security updates.
Can you clarify whether the block only applies to the app as such (1), or does it possibly affect all non current major versions that have not been deployed since 2023-01-01 (2)? In other words, which of the two interpretations applies:
Given a more recent major version deployment, all previous major versions last deployed before 2023-01-01 are unblocked as well
Regardless of whether a newer major version has been recently deployed, all previous major versions last deployed before 2023-01-01 remain blocked until specifically updated via forge deploy --major-version
I’ve identified two installations with a major version last deployed before 2023-01-01 where a scheduled trigger still runs hourly, so if the block is already in effect as suggested by the announcement, it seems accurate and the block only applies to outdated apps, i.e. interpretation 1 in my question.
Regardless of whether a newer major version has been recently deployed, all previous major versions last deployed before 2023-01-01 remain blocked until specifically updated via forge deploy --major-version
So it could be the case that you have a subset of customers on an old major version who get blocked but the rest of your customers on newer versions would be fine.
As you said, you could run forge deploy --major-version on those old versions to unblock customers. Otherwise they will have to upgrade the app.
Also, the block will be rolling out gradually so it won’t be the case that all customers break at once.
Adam, I hope you’re aware that backporting feature is completely inadequate?
It only allows minor updates. So if any permission scopes have changed at all between versions then it requires a major upgrade which requires a manual update from customers.
And permission names and requirements have been changed multiple times in the past few years. You can’t migrate from UI Kit 1 to UI Kit 2 without changing permission scopes. Similar permission scope changes in many @forge/* packages.
Has any thought been given to this situation? Do customers on old versions simply now see broken apps? Is there any info message displayed on these broken apps to push customers to update them? Is there any notification to prompt admins to update apps?
At quick glance on a few apps it looks like 10-30% of all my Forge installs will be broken due to this decision. And there’s nothing I can do about it. Why would anyone build apps on this platform?
But can you then easily apply that to every past major version going back multiple years?
I’m guessing one would need to go through each and every major app version, load up the code at that point in time, change CLI version, change the runtime, test the app, deploy the minor version, backport within that major version.
That’s how we did it, except that we always used the latest CLI version.
I think a requirement for this is that you keep track of the app version numbers in your SCM. For example, we tag every release with the app version number in Git. This allows us to update the runtime property in the manifest for the latest minor version of each legacy major version.
I wouldn’t know how to do that without a link between commits and app versions.
Thanks @AdamMoore, the changelog entries have been pretty misleading then, given the major version update problem is well known to cause significant partner pain and could have been explicated accordingly (like you just did) - two resulting asks:
Can you share a screenshot how the error manifests for the end user? We are obviously unable to recreate the conditions for a block, but presumably you have tested the user experience and implemented contextual app upgrade guidance for affected users?
Can you postpone the rollout for another month or so? I’m sure we are not the only partner who didn’t realize in time that this will affect all outdated major versions, and while I’m happy that those can be updated meanwhile, a scalable solution had been a backlog issue that we now need to implement on short notice over the coming weeks.
I agree with the sentiment here - we didn’t do a great job supporting partners through this deprecation and I’d like to learn from it. If you are unduely impacted please use this link to grab some of my calendar time next week. Lets talk about how we can get through this one together and I can use that in modelling a better way of doing things going forward. I am working with our internal teams to analyse the impact of the immediate Runtime v1 and UI Kit v1 deprecation. This will include a broader review on how we manage deprecations and our messaging.
I agree versioning scheme isn’t very good and it creates a huge amount of headaches for our teams internally too. We are feeling the same pain here. We do have plans to unbundle the concept of version upgrades from scope and permission changes, so that the latest version of the app is always running but the administrator would approve changes to permissions and egress. It’s a model that other enterprise and consumer platforms use but it will require some defensive coding on the developers side to check if you have been given permission to access data or to contact services outside of Forge. There will be an RFC and I welcome you to collaborate with us.
I would also like to address conduct on this forum. We have incredible people working across many teams to deliver Forge and they are thinking about how to improve the experience of partners and our customers every day. However, we are not infallible and sometimes we don’t get things right. When the sentiment becomes negative and borders on the personal, it is felt by ~200 people and the culture that pervades as a result is one that is overly careful and defensive. It helps no one, so please help me change that.
Thanks @JamesDumay, highly appreciate the plan to evolve Forge towards a more industry standard optional permission and egress handling unbundled from version updates, and also your offer to talk about the partner impact of deprecation management and messaging and how to improve on this going forward
That being said, can you also address my IMHO reasonable asks on a) the customer experience resulting from this deprecation (helps with our own resp. messaging and support), and b) postponing this rollout for a bit (which would significantly defuse the impact, as has been done by your teams multiple times in other contexts)?
Just getting an option to “talk about how we can get through this one together” next week seems to imply you already decided to continue with the rollout despite the potentially significant impact on our mutual customers (and partners do not even know its exact timing and scope)?
Those two asks are very reasonable. Let me see what I can do. Could we have a quick chat next week to align on those expectations? If you can’t find a good time drop me an email on jdumay@ and I’ll make the time.
Just to emphasize this again, the most important aspect affecting all partners equally is getting an answer to my question 1/a, i.e. whether the major version block manifests for customers as an unspecified app error (bad) or as dedicated upgrade guidance (problem likely solved for many apps)? I’m a bit puzzled why this seems difficult to answer
It’s an unspecified error that usually manifests in a blank panel. Let’s talk about what we can do there, some nuance to it that I need to figure out an answer to.
At least one of my paying customers is affected by this. I am contacting them urgently (again), asking them to upgrade ASAP but I cannot force them to upgrade. The minor version deploy option will not work in our specific case (happy to explain why).
What I do not understand is that this was the perfect opportunity for Atlassian to build something that urges the customer to upgrade the app. Yet, all the customers sees is behaviour that makes it look like the app is at fault. What a missed opportunity.
We really need a solution VERY soon for urging users to upgrade through the Jira/Confluence interface. Maybe something like the ability to deprecate old versions, and then Jira/Confluence puts “please upgrade this app asap” all over the UI. Or a solution where the vendor can force the upgrade by other means. I have customers on a UI Kit 1 version of an app that will soon stop working as well.
Please, please, please, pretty please. I am about to lose business over this.
