The point here is that all of these would link against something like "gtk-4-unstable.pc" which makes things easy for distributions to know what needs to be recompiled when they bump dependencies.
So while it semantically is the case, I don't think it is as big of a deal as you are claiming.
> Even though Gtk3 is still riddled with regressions compared to Gtk2
Gtk 2 hasn't changed in over 5 years. So I'm not sure it's suitable to compare against anything.
> and there's no stable theme interface, and for example the Raleigh theme engine completely broke in 3.20, the GNOME devs seem to have decided to take it to the next level.
The stable theme API landed in 3.20. That is a first time in my nearly 18 years of working with GTK. While the Raleigh didn't "completely break" as you say in 3.20, it hasn't been the "default" GTK theme for quite some time.
> Yes, gtk2 has limitations, but there was ABI and API stability on all layers.
I worked on one of the largest gtk2 applications shipped to date (the VMware Linux product line) so I have a little background on the topic. I also happen to be an upstream GTK developer now since I left VMware 5 years ago.
And, quite frankly, this statement is incorrect. Plenty parts of GTK 2 were unstable during it's lifetime. In particular theming and gtkrc bits. I've written enough workarounds during the lifetime of gtk2 products to know. That is simply the reality when a piece of software tries to remain ABI stable for over a decade. It's really, really, really hard work (and as this post shows, almost completely thankless).
The only reason gtk2 is stable today, is because it's generally not touched (except for very specific bug fixes).
You'll see gtk3 be considered stable in the near future, but with a longer lifetime of bug fixes than gtk2 has gotten. Some of us are arguing for in 6 months, some for a year'ish. Meanwhile we will develop and stabilize gtk4 to land in the next series of long lifetime releases. We haven't hashed out all the details yet, but that could mean that if you subscribe to our 6 month release cycle, you might depend on say "gtk-4-unstable.pc". Where as, once we start on gtk 5, you can depend on "gtk-4.pc" and everything is guaranteed stable going forward. Those on the GTK release cycle will then consider moving to "gtk-5-unstable.pc".
By moving our major numbers sooner, it's very clear that the major version you are on is no longer game for major changes. I wish we had a butter way to deal with what we call the numbers (4.6 being 'stable' for example), but semantic versioning here isn't really sufficient (nor simply soname versioning alone).
We couldn't really come up with a better naming system than to say something like "4.6 is considered stable". This is a complex problem because we can either require everyone to bump their pkg-config dependencies again once they know they are stable, or not. We discussed doing something like 4 stable and 5 development, 6 stable, etc but ultimate decided against (as much as a half day decision can be) due to the churn it would take maintainers to update build system.s
This is mostly made more difficult because of distributions. They often deal with packages that are written and then stagnate for a couple of years and would like them to keep working (Debian Testing → Stable for example).
We've only discussed this for half of day-one of our current hackfest, so of course, if you have input, this would be a great time to join #gtk+ and make your voice heard. Many of us are here in Toronto in person, but we are certainly still all on IRC listening to users there.
> Had Gtk3 only added Wayland and HiDPI support, and kept API stability for the most part, we wouldn't find ourselves in this unfortunate situations.
If only we thought of it!
Sorry for the snark, but your comment really trivializes the amount of work it goes into such features. It is really hard to have a reasonable discussion unless you are willing to sit down and look over the last 5 years of development and how each incremental feature plays a part in building a modern toolkit.
We want to do much more modern things (like GL/vulkan rendering for example), and the recent half-decade has shown that is pretty much impossible for us to do without applications willing to test how well things work. That results in the natural feedback loop of improving things. Now, having both developers that want to write code and largely ignore it for 5-10 years is a different set of developers than those that are willing to stay up to date with the toolkit and test features as we add them. They are both completely valid desires of developers. We are stuck trying to satisfy both, which was not obvious when we started. When GTK3 started we thought it was going to be a "break everything while we figure out what GTK 4 will look like". As you can imagine (especially with hindsight), easier said than done.
Each incremental change that has happened from 3.0 to 3.20 is monumental in turning a toolkit that was state of the art for 1998 into a toolkit that is state of the art for 2016. I'm not going to rehash the gigantic list of all those features, as people have done that elsewhere already today. We still aren't where we want to go, but each change we've introduced has been a step in the progression to get there.