GTK doesn't use semantic versioning.
Every uneven minor version is a development cycle, every even minor version is a stable cycle.
And as it happened so often, every dev cycle things broke down, because of intertwined dependencies of GTK, gjs and glibc (and gobject introspection bindings).
See also: https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta...
I also think you're kind of proving my point. If the project that is supposed to be _the demo use case_ of the _GIMP Tool Kit_ and needs more than a decade to update its scenes, views, and widgets...then maybe this is not the right toolkit for anyone, because pretty much every CEO will go rogue when they see the development time needed to port anything to GTK.
And it doesn't have to be like that. It's an architecture design decision they made, where they also chose vala as their own NIH programming language to integrate things over other more established options.
Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins.
My point is that the GNOME project introduced maintenance burden upon themselves, and that's what's killing the GTK ecosystem. And they themselves could have avoided that.
(Apart from the outdated documentation whose example demos don't even compile, whereas the getting started effect with QML is a matter of minutes, not days)
I don't wanna derail this discussion too much. It's great that GTK is evolving and adapting. I just wish they would focus on ease of use rather than inventing their own tech stack wherever possible.