By now it is probably no longer news to many: GNOME Shell moved from GJS’ own custom imports system to standard JavaScript modules (ESM).
Extensions that target older GNOME versions will not work in GNOME 45. Likewise, extensions that are adapted to work with GNOME 45 will not work in older versions.
You can still support more than one GNOME version, but you will have to upload different versions to extensions.gnome.org for pre- and post-45 support.
Please file bugs with your favorite extensions or have a friendly conversation with your extension writers so that we can help minimize the impact of this change. Ideally, you could help with the port and provide a pull or merge request to help maintainers.
I am a daily Gnome user. There are many things which I actually dislike about Gnome, but I have solved them all through extensions. Fine, I’m not bothered because it can be customized.
But every time they introduce something like this, it takes me a while to get a functional desktop back. It takes time for those extensions’ developers to respond to these things. They have to research the change, implement it, test it, go through extra work to stay backward compatible, etc. These people aren’t being paid for this, so it takes some time.
I’m just frustrated about this. I know someday I will run updates and suddenly find all my extensions broken.
I mean there are a bunch of GTK based desktops besides Gnome already. Mint team’s Cinnamon, Budgie, Pantheon, Mate and of course: XFCE
The ideas behind the GNOME Shell desktop metaphor have stayed consistent through the 3.x cycle, at least from ~3.10. The “problem” with GNOME 3.x is that it implements core ideas in the workflow that the user needs to grasp. Either you use it as they thought you should or you are better off with some other DE.
Sure, you may need some extension to feel more comfortable. I do use a couple, but if you need extensions to make it functional you really should consider switching to another DE/WM.
I really like a lot about Gnome. It’s things like getting rid of the system tray that don’t make sense to me. I understand it’s not in the system’s ideology, but you can’t force that on every application developer who still has to support that feature for other desktops. If it’s a common application feature, then it’s just broken on Gnome. That’s a hard thing to sell me.
It will be annoying for a minute but this change is good: it will help developers ship extensions faster and with fewer bugs by using standard JavaScript modules and IDE support. As mentioned in the blog: modules were standardized in 2015! At what point does it become acceptable to drop non-standard features?
it will help developers
Until they break it.
ship extensions faster
Which they need to adress the regular breakages.
and with fewer bugs by using standard JavaScript modules and IDE support
If I wanted to suffer web technologies, I’d develop content targeting web browsers, not a DE. JavaScript does a lot of things, being conducive to bug free code is not one of them.
I really admire the pain tolerance and endurance of devs developing and maintaining extensions for gnome. At what point does it become acceptable for them to drop that garbage DE? Rhetoric question: always has been.
Extensions that target older GNOME versions will not work in GNOME 45
So basically it’s just another GNOME release gotcha.
Seriously though, a stable API is not the GTK/GNOME developers’ agenda here. Nobody wanting a stable API should write software with this toolkit. That said, if you’re a true front end aficionado and you’re looking to make your software look awesome every six months, GNOME has got you so covered like the chocolate on a peanut M&M.
For those wanting to write software that won’t magically kerslode without yet another recompile (or heavily relying on your distro to do that dirty work) stick with KDE/Qt group. They tend to be less breaky each release.
So basically it’s just another GNOME release gotcha.
AFAIK, the extension developer needs to explicitly set each version of Gnome they support. Even when the Gnome version doesn’t have any breaking changes, the extension developer still needs to update their extension to enable their extension for the new Gnome version.
It makes sense that you have to explicitly verify that it works on every release - even if there had been no intentional breaking changes. That said, if an extension developer would really prefer to YOLO it, they could just pre-emptively add a bunch of future releases.
(Of course, ironically that would’ve broken when they switched to 40.)
It would make more sense to specify something like API versions, not software versions, and flag on the client when it changes without the addon being updated (giving you a choice to run it with a warning or not). That is, unless the version update is specifically flagged as breaking compatibility, in which case it would just warn and not offer to run it anyway until it’s been updated.
I had to orphan a very simple extension I wrote for gnome 3.2-3.10 It was a bugfix that for some reason upstream didn’t even want to acknowledge it existed, and never accepted the patch. So I made the extension, but after about a year of constant breakages I gave up.
That ordeal really made me feel unappreciated as a contributor.
Seriously though, a stable API is not the GTK/GNOME developers’ agenda here. Nobody wanting a stable API should write software with this toolkit.
This blog post doesn’t mention GTK, but I’ve heard GTK will sometimes implement breaking changes in minor version bumps. I was thinking about writing some software with GTK, and I haven’t been deterred so I guess I’ll learn the hard way, but has GTK 4 had any of these stability problems yet?
See, this is the beauty of running Debian stable as your daily driver. I’ll be on Gnome 43 for two more years, so by the time I upgrade to Gnome 45+ extensions should be compatible. Only half-joking, I really do avoid a lot of early adopter regressions and breakage.
Arch does too, albeit to a lesser extent. Gnome updates usually take around 4 to 5 weeks after the official release to hit the Pacman repos.
Means you can stay bleeding edge but avoid day 1 breakages for the most part.
I will say, as a JavaScript developer, the new module system is a pain everywhere. Node.js went to great pains to allow for an upgrade path without breaking changes, and it’s still a PITA for developers because there are so many edge cases that could go wrong, so you still have to actually keep testing in both older and newer versions.
A hard break like this is painful, but I’m not sure if there’s a better solution. On the upside, it looks like it’ll be easier for someone like me to contribute fixes for this, even if I don’t know the specifics of extension development otherwise.
