I’m just going to place this in Community because I don’t think there’s a better place.
For some time, it was the default for most if not all distributions to ship GNOME Shell with the extension version lock on, which meant the shell actually paid attention to the Shell versions an extension claimed to support.
After some time, things settled down in GNOME Shell and the “APIs” most extension authors were using generally stabilized, and presumably this seemed like a good time to turn it off. Really, this just meant a user didn’t have to manually add the latest version to metadata.json and restart the Shell. With the latest release of GNOME Shell, the overdue removal of ShellGenericContainer and general deprecation of things like Lang, some users have experienced some more serious problems than just their extensions not working.
There have been a lot of changes with GJS (and JavaScript) since the version lock was turned off and code that could be updated to take advantage of them. This could give developers and users a bit of a safety net and opportunity to clean out some cruft, so it seems like a good time to ask if we should turn the version lock back on. Thoughts?
Changes in the Gnome Shell have nothing to do with a “stable API”. Significant changes have also occurred in GJS, or Mutter, or other related modules.
I generally think that the version checking mechanism for extensions should always be active, that’s why it exists. Disabling it is not the safest solution for ordinary users (neither pleasant for the authors of extensions).
Florian and I are the people responsible for the strict versioning turned off at the time. I was approached by a distro about fixing the broken extension issue.
I think though that we can’t do this without implementing a process. This is something I’ve been thinking on because we will still have issues with extension writers not updating their extensions, but more than that, we have to ensure that we have reviewers who will approve the updated extensions. Otherwise, we just get a long queue of extensions that hasn’t been updated.
I’m evaluating an idea that I hope I can make happen which is to create QA system around extensions that can do things like auto-update. I have gotten someone to help manage it, but the work I hope will be done by folks on openQA who I believe have tests already.
Thanks for the response. I understand GJS and Shell extensions are both still moving targets and infrastructure for handling them has been a tough problem to approach.
I think though that we can’t do this without implementing a process. This is something I’ve been thinking on because we will still have issues with extension writers not updating their extensions, but more than that, we have to ensure that we have reviewers who will approve the updated extensions. Otherwise, we just get a long queue of extensions that hasn’t been updated.
Yes, I’ve recently volunteered to review extensions, and I think I’ve been doing pretty good keeping it under a week for review time.
The reason I brought up the version lock, is that for the vast majority of users the supported versions are entirely ignored. From my perspective as an extension developer, this means I get many issues opened by users who are unaware they have installed my extension for an unsupported version of GNOME Shell.
In the most recent release, a minor typo in the introspection annotations led to several performance and bug reports in both Launchpad and upstream caused by my extension.
I’m evaluating an idea that I hope I can make happen which is to create QA system around extensions that can do things like auto-update. I have gotten someone to help manage it, but the work I hope will be done by folks on openQA who I believe have tests already.
I had a very brief chat with Neil about this, and he pointed me to an example of how (I believe) OpenSuse was using this. I also believe there is some static analysis that could make the review process easier such as checking for known methods to spawn processes, paired signal connect/disconnect, GSources, things like that.
I’d be open to being involved in any discussion about this and contributing to the solution, so feel free to CC me on any related GitLab issue.
Perfect. Neil and I have talked about this since he’s primarily been using his time to approve extensions and I know it is a headache for him. Having you onboard definitely helps. But we can do better. I have all kinds of ideas like being able to know how many extensions broke as part of a MR request.
Let me make an introduction to our project manager handling it and maybe you and I can help approach opensuse/richard brown about leraning how they do their QA of extensions? Putting work into this will reduce our workload quite a bit later.
I have all kinds of ideas like being able to know how many extensions broke as part of a MR request.
Me too, but I’ll hold off on the spitballing until we get a good place to brainstorm and set some goals. I think there are some other good people to CC in like Yuri maintaining SweetTooth that will have some good insights.
Let me make an introduction to our project manager handling it and maybe you and I can help approach opensuse/richard brown about leraning how they do their QA of extensions?
It doesn’t seem to be working on Fedora 30. Anyone else successfully installed it?
Incompatible with 19.04
Not working on my Gnome Shell 3.32
It does not work in Ubuntu 18.10
Still error in Ubuntu 19.04
Error installing in ubuntu
Broken on Gnome Shell 3.32
Still broken
Not work
etc.
And reporting issues like this:
Your extension had broken again
No - my extension is ok, but it is not for Your Shell version; please do not change metadata.json file; I’m working for update
But I’m installed it from official GNOME extensions site
Perhaps the issue is not so much the version lock itself, but the fact that it’s keyed to something that is, for the most part, a loosely-related, almost arbitrary value: The GNOME [Shell] release.
The version lock became an annoyance when, as @andyholmes says, things sort of “settled down” on breaking changes to the APIs that extensions were making use of. Things got to a point where it at least seemed like 90% of extensions were completely unaffected by the differences between, say, GNOME 3.14 and GNOME 3.16. (A random example, I have no memory of what actually changed between .14 and .16.) And many probably wouldn’t be affected by 3.18 either.
Nevertheless, every six months all extensions had to be updated, even all the ones where the “update” consisted of nothing more than adding “3.16” to a list in metadata.json.
Is it preferable that all active extensions get reviewed every release, to ensure they’re still compatible? In an ideal world, sure. But a more focused approach might be for the APIs to somehow be versioned… well…
Separately from the GNOME release. (Or, at least not automatically with the GNOME release.) So that version bumps are more indicative of actual changes that extension developers would need to react to, and not just what can be perceived as a call to rubber-stamp a new update.
With more granularity than the GNOME release. I’ll be the first to admit this sounds totally unrealistic, given the scale/complexity, but it’d be an amazing thing if even just a few of the major APIs were versioned independent of the GNOME release itself. So that when ShellGenericContainer is removed, all extensions (…period, probably, but) all extensions that touch the Clutter APIs know they may need an update. And if GNOME 3.34 ends up leaving Clutter alone, but brings some breaking changes in imports.gi.Gio, then that may affect some extensions, but the ones that never use Gio are still compatible.
As I said, probably unrealistic. But who knows? Maybe some sort of modularization ala Node could replace the metadata.json release-gating, somewhere (way) down the road?
