Replies: 3 comments 1 reply
-
I don't think we have explicit conditionals based on the version, but we defensively programmed around some APIs that changed by checking whether certain fields exist before touching them. After 1e9004d there are changes which may not even be compatible with gnome 41. I doubt there is much value in maintaining compatibility with gnome 41 in master, we can just not release further versions for gnome 41. If people want to continue to make bugfixes for gnome 41, we can do that in a branch.
The extension, as far as I can tell so far, is mostly a plugin which heavily relies on private gnome APIs and state. I am not sure there is much to be gained by creating abstractions here. In the end, I guess there's a question of how much effort we want to put into supporting new features on multiple versions of gnome concurrently. My guess right now is not much, but maybe there are people itching to add new functionality on older distros who will show up at some point... |
Beta Was this translation helpful? Give feedback.
-
I am in favor of creating Gnome-version-specific branches to maintain compatibility, but concentrating development on the latest Gnome release. Backports of particular features or fixes could be made by those interested. This is mostly to maximize the available developer effort we do have. I've seen other projects maintain ever-growing stacks of compatibility functions to retain Gnome API compatibility, and this makes it very difficult to correlate with upstream documentation and understand the code. An alternative would be to create a separate library for GJS API compatibility, which would be more useful, more maintainable and easier to document, should other projects decide to use it. This should really be done upstream, though. |
Beta Was this translation helpful? Give feedback.
-
One thing I ran across today: breaking backwards compatibility can reduce the pool of contributors. When I was asking people to help test #9, it occurred to me that the patch may not apply cleanly after we merge #25, so people who are on Gnome 42 would not easily be able to test. The PR could be updated to apply to gnome 42, but then people like who are still on Gnome 41 (like me) might not be able to apply it easily. I still think that we should not maintain backwards compatibility with all versions. But maybe it makes sense to target something like the most recent 2 versions, and then use branches for anything older than that? That would support anyone who is on a currently-supported version of Fedora. If we wanted to support the latest version of Debian, Bullseye is currently using Gnome 3.38. It's hard to gauge how big a benefit this would provide, though. Maybe we can just do it on a case-by-case basis, depending on how difficult it is to maintain backwards compatibility with a given version. |
Beta Was this translation helpful? Give feedback.
-
Preface: I am not familiar with the code base, so this contains a lot of speculation. Please correct me if I'm way off base.
In #25 (comment), @xanf wrote,
How many of these exist? The top of the README says,
Based exclusively on that statement, it seems like the architecture is, or should be, two layers:
With the exception of the preferences, all the compatibility code would live in the bottom layer. Instead of one implementation with a ton of conditionals for different gnome-shell versions— terrible to maintain —you'd have one switch statement up front, between different api versions, to pick between several different implementations. When a new gnome version breaks compatibility too badly, you'd add a new case and create a new implementation for the new api version, without having to worry about backwards compatibility.
Yes, it would be a lot of code (probably also lots of duplicate code), but it wouldn't need to change very much. The one exception would be if you needed to add something new to the bottom layer's interface, to support a new feature in the top layer. For that, assuming nobody wants to do the work of implementing it at all api levels, you could instead mark the extension as only compatible with the latest gnome-shell and replace the calls to the older api implementation with an
Error('Not implemented')
(but leave the code). Then if someone comes along later and wants to add support for an older api, they have a clear task: implement the new interface in the older api level.I can imagine that the current code might not be implemented this way, or that it might not be possible without rewriting large portions of gnome-shell itself. Anyone more knowledgeable want to chime in and either shoot this down or entertain the idea?
Beta Was this translation helpful? Give feedback.
All reactions