Re: New versioning scheme in gtkmm? In glibmm?

[Murray Cumming <murrayc murrayc com>]

On Fr, 2016-09-23 at 16:51 +0200, Kjell Ahlstedt wrote:
> Gtk+ has announced a new versioning scheme:
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-pr
> omise-in-gtk
> I suppose that it will affect gtkmm. Will gtkmm use the same
> versioning scheme? If so, I suppose that once a gtkmm-3-22 branch has
> been created in the git repository, we shall start removing all
> deprecated API in the master branch. And fix bug reports that require
> an ABI and/or API break. Am I right?
> Will glib use a similar versioning scheme? I.e. soon an ABI/API-
> breaking glib 2.90 release and then glib 3.0?
> Kjell

It's very hard to know what they really intend, or what will really
happen. But it looks like this is what they want:
* GTK+ 4.0, 5.0, 6.0, etc, will be stable releases (installed in
parallel, as we'd already expect).
* GTK+ 3.9*, 4.9*, 5.9* will be unstable releases of those APIs.
* These will take longer to become stable releases, compared to the 6-
monthly cycles we have now, with releases such as 3.2.x, 3.4.x, 3.6.x,
etc.

So it just looks like they want to take much longer between stable
releases that add new API.

That doesn't seem so different to how it was a few years ago before
GTK+ finally synchronized with the 6-monthly GNOME schedule. It didn't
work very well then. Too many people won't try new API until they are
fairly sure that it's going to be available soon. And without a firm
stable release date they cannot risk using it in GNOME application code
that does have a firm release date. So the GTK+ developers won't get
feedback until long after they've committed the code, and often won't
get that feedback until too late, after they've declared the API
stable. This is why we have time-based releases.

I don't think it's likely to work so I'd rather just wait and see what
actually happens. At the least, it just looks like a suggestion that
they want to start working more now on a parallel-installable GTK+ 4.
That would be nice but I don't see how that's much more likely to
happen quickly now than before.

I'm happy for us to try targeting GTK+ 4, but I wouldn't do that in git
master before GTK+ 3.9/4 is in git master.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com