Ngl, I'm low-key tempted to just list several future, not-yet-existing gnome versions as "supported", considering how tiny the "surface area" of this extension is and how unlikely it is to break. It'd be less hustle to jump in and fix it _if_ it break, instead of having to bump the version manually each time. Gnome could really use some kind of automated forward-porting framework to automatically test existing extensions to see whether they have been broken or not, and mark them as supported without human intervention in case they're not.

The thing is, not all extensions only monkey patching at enable. Most of them doing it after enable (by giving users options in prefs) and that makes testing them very hard.

I understand that. It could... No, _should_ be an opt-in system. For example, extensions could mark themselves as forward-porting by proving a method like "selftest()", for example. If an extension does that, then, whenever a new version of Gnome is released, all the extensions capable up self-testing could be tested, CI/CD style: the whole code could be checked for deprecated imports, function uses, etc. If no deprecated uses are detected, then selftest() method could be execute, in which the extension would attempt to... Pretend that a user is using it, doing all kinds of runtime patching and checks. Any exception raised during execution of the method, would prevent auto-version bump. Sure, it's not a bulletproof system, but it could be helpful for extensions that are mostly... self sufficient, for lack of a better term. I'm using 15 extensions right now out of which only 3 or 4 have been ported to 47 officially. The rest just work, because nothing those extensions use has been changed in this update. By implementing automating testing for some of those extensions (those that are simple enough to actually cover all of their features in tests), the "downtime" could be significantly reduced, I think.