This is a reminder that we have reached the end of the deprecation period for running Node 18 on Forge. The Node 18 runtime is now unsupported.
Attempting to deploy a Forge app (new or existing) using the nodejs18.x runtime will fail. Apps must upgrade to a supported runtime version before further updates are permitted.
Node 18 is no longer maintained by the Open JS foundation, which means that over time it will become susceptible to security issues and functional degradations.
Users of apps running Node 18 will see no interruption to functionality. We’re working with the admin team to build additional disclosures in the app administration interface that indicates apps that require action due to deprecated components. But to your point, we know that this doesn’t address the underlying problem of apps not being updated by administrators.
You guys continue to fail to solve the existentially disastrous problem of versioning on Forge.
I’m sorry that we don’t have a roadmapped solution for this yet. I know it’s small/no comfort, but we are advocating for improvements in this area internally.
There continues to be zero effective means for developers to push customers onto the latest version of their apps.
Have you considered building an update check into the app yourself to notify users/administrators when a new version is available? Not a silver bullet, but could help.
And the longer this ball is dropped the worse the problem gets. Not uncommon for 90-99% of app installs to be running outdated and broken Forge apps.
The compounding effect of this issue is definitely not lost on me.
I could build that but then I’d have zero practical way to deploy that update to customers.
Yes there is the useless backporting feature but you can only deploy minor updates within major versions.
I was a very early adopter of Forge. Most of my Forge apps are now past v12. Which means I would need to individually test and backport 26 Forge apps for every single major version: 26 * 12.
And all of that is only feasible if I have a carefully tagged version release marker in git going back to the beginning, which I don’t because I assumed Atlassian would have had the competence to solve this problem many years ago.
Every single deprecation, permission scope change or anything that results in a major version simply compounds the drop-off in users running the latest install.
Now run this scenario in the case where you have free Forge apps with 90-99% of installs on outdated versions, and you want to convert those apps to paid.
How many of those customers do you think will convert to the paid version if none of them are manually updating apps?
Absolute disaster, massive loss in revenue, dead-end business, zero point building apps on Forge because there is no business case.
I could build that but then I’d have zero practical way to deploy that update to customers.
That’s true, but it would insulate yourself against future major versions you’ve yet to release. Or perhaps there might be some low hanging fruit where taking on the effort of back porting this change (which as you point out below is not a straightforward job) to only a select subset of major versions could have an outsized impact.
I’m happy to engage in productive conversations with the community about how we can improve the platform for you.
I have acknowledged your frustrations regarding old major versions and agree with you that the problem is a big challenge for developers, for customers and for Atlassian. There is a project forming internally to address this and I hope we can get it funded and prioritised and share our ideas here with you.
I’m not happy to be held personally responsible for the entirety of everything Atlassian has ever shipped. I understand that you’re frustrated with a lot of things. Missing functionality and decisions you disagree with have a fundamental and direct impact on your bottom line and your life as an entrepreneur/small business owner.
I don’t think it’s fair to call us incompetent because this problem has not been addressed. I hope you can appreciate that the challenge is one of relative prioritisation/impact.
Nowhere in the developer docs does it say “oh btw while we say this is a cloud platform, the DX is more akin to building server apps in 1999 because we haven’t solved versioning yet… so make sure you carefully tag every single release in git… and don’t even think about releasing a free Forge app if you ever plan to monetise it”.
Thing is I’ve been screaming about this problem for years. It’s a death spiral for all marketplace partners. I’m simply one of a few canaries because of how early I built Forge apps (UI Kit 1). The problem will compound until it destroys the businesses of marketplace partners.
I’ve had multiple Zoom calls with internal Atlassian’s to talk about this.
Basic solutions have been overlooked that could have been implemented years ago and are still missing to this day: eg notifications to admins within the core product.
Suggested future solutions I’ve heard like “versionless apps” will make the code complexity too high for the majority of partners. Unless that plan has radically changed since I last spoke to them it will involve developers having to switch on/off features depending on what permission scopes admins have approved. ie an infinitely complex nightmare to manage.
The entire point of modern cloud-based agile software development is you move fast, deploy multiple times per day, and sync all customers onto the latest version. It’s a operational and security nightmare to have 90-99% of your customers spread across all prior app versions.
And it’s worse than building server apps! With old-school server apps at least your customers could still have functioning apps despite not running the latest version. Whereas when Forge deprecates something like the runtime or UI Kit, that means customers running old versions literally have broken apps. Remember I had to beg you guys to add any fallback UI messaging the last time you deprecated the runtime!
The longer this goes unsolved while deprecations continue to happen, the faster this entire ecosystem will collapse.
I appreciate the ongoing dialogue around this challenge, though I think we are in a bit of an endless loop here.
While I understand that implementing a comprehensive solution likely involves coordination across multiple teams at Atlassian and presents genuine technical complexity, I suspect the collective time and energy that Atlassians have invested in community discussions around this issue over the years may already outweigh the implementation effort required.
Simple measures like admin notifications within the core product or giving marketplace partners more control over driving customer updates would already make a meaningful difference for the ecosystem.
I believe that most Marketplace partners as well as Atlassian wish to have a constructive community where people can feel safe. One part of that is that people try to express themselves in a respectful and professional manner. Another part of this is to try and interpret what is written in best intention. Communication is a two-way street that works best when both ends work on being constructive.
Please do not interpret this partner’s frustration as a personal attack on yourself in which you are personally being held accountable. Part of acknowledging our frustration (like you claim you do), is to understand where it’s directed. I can assure you that most partners that express their frustration and worries in threads on this forum are actually targeting this at the entity Atlassian, which you happen to represent as the Atlassian Staff person in this thread. I believe that no one here is holding any single Atlassian employee accountable for all Atlassian’s decisions, but as one of our only means of communication with Atlassian the company, we have to message you employees through this channel.
Whenever you are writing here representing Atlassian, I think it would be prudent to try and receive feedback as “Atlassian” and not as yourself, though I can completely understand that this is not an easy thing to do. We as the partners reading this thread on our are aware that it is Atlassian that is deprecating the node 18 runtime on Forge, and not you personally. It is obvious that you are just the messenger on behalf of Atlassian in this instance. Thus, the entity we are responding to is actually Atlassian, not the messenger.
Of course every party should try to communicate more kindly and in a manner that is not hurtful, but it’s easier said than done (especially when one is frustrated). Let’s remember that written communications have a tendency to be interpreted in a more negative manner than was intended by the person writing the message, so strive to assume best intent.
We’ve built an update check using the Marketplace API, but we’re going to remove it soon because it’s not compatible with Runs on Atlassian.
What would help a lot would be to get the latest published Marketplace version in the app context. The app context already contains the appVersion, so we could compare both values and show an update notification in the app if necessary.
Atlassian/Forge should really fix the issue with version updates. We have a simple app which has now 7 major versions. The number of major versions is only going to increase.
When you deprecate something, you break the app for most users. The current backport feature is totally useless in practice. Do you expect us to backport to 7 times when one thing is deprecated? Mind you, the earlier versions cannot even be built because the libraries are so old.
Why am I saying this again? We expressed these issues many times, to many people at Atlassian. No wonder, partners are flustrated and angry.
I apologise for engaging with the community with a poor mindset.
You are of course very welcome and encouraged to share your frustrations with Atlassian in this forum, to a representative of Atlassian, of which I am one! Without this feedback, we cannot grow or see beyond our own echo chamber.
@nathanwaters I apologise for any aspersions I cast on you. Thank you for continuing to share your feedback. I will continue to advocate on your behalf for improvements in this area, when I am able.
Thanks @klaussner - this is quite actionable. Would it also be workable if we just sent the latest version in the same environment into the app context? This would simplify the work required, make it testable in dev/stg, and also avoids introducing new slow dependencies on the Marketplace API into the invocation overhead.
Let me check in with me team and see if we can sneak this in somewhere. I know it’s not a solution for the broader problem, but still a worthwhile improvement.
What if we made outdated versions more clearly visible to admins? Right now, having to manually open the UPM to check feels like it contributes to the inertia around updating. There are plenty of popups and in-product notifications highlighting new features from Atlassian itself, but as vendors, we don’t have that opportunity. I don’t ask for a custom module, but a built-in system notification “there are app updates → link to upm”.
While this won’t solve the deeper issue of customers resisting updates (or upgrades to paid versions) it would at least ensure they’re aware that new versions are available.
I think the best solution is opt-out automatic updates, eg…
Minor versions: instantly auto-update.
Major versions:
Devs push a new major app version.
Admins are given X months of system notifications.
They can either one-click update the app or uninstall.
If no action is taken the app automatically updates.
Atlassian can auto/manual review the app just before step #4 happens.
Same for converting free>>paid apps but you simply use or extend the existing refund policy if the admin takes no action, and Y months later they decide don’t want to pay for it.
If you think through all possible ways to solve the problem I can’t think of any better:
simple solution with very few moving parts or complexity.
all installed marketplace apps will be at most X months out of date.
the current mess of 90-99% of installs being old/broken will auto fix itself.
moves complexity away from devs who shouldn’t need to handle this.
avoids in-code handling of infinite optional permission scopes (Forge current plan ).
gives admins ample opportunity to take action on their own terms.
includes a final review step to prevent bad actors stuffing scope changes.
Hi @klaussner - the exploration we did this work shows this unfortunately isn’t a quick improvement. The service responsible for invoking the Forge function doesn’t have information about the latest app version, and pulling that in would change the performance/scale profile of the service quite dramatically.
I’m keeping this on my radar for medium term, but won’t be able to turn it around quickly, I’m sorry to say
).