Re: New versioning scheme in gtkmm? In glibmm?

[Chris Vine <chris cvine freeserve co uk>]

On Mon, 26 Sep 2016 22:26:01 +0200
Murray Cumming <murrayc murrayc com> wrote:
> 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 isn't really it.  The intention is that API/ABI will be broken with
every new major stable release, as at present (so 5.0 will be API/ABI
incompatible with 4.0, and so on), but that these new major stable
releases will come out at a much higher rate than at present - every 2
to 3 years. This is supposedly firstly to allow for a higher rate of
innovation (official breakage), and secondly to reduce the amount of
unofficial breakage between ostensibly stable and compatible releases,
which has caused problems with the 3.* series.  Successive incompatible
stable releases will come out more frequently, but within any major
version compatibility will be more rigorously enforced.  In particular,
once a new major stable release has actually come out, thereafter it
will only receive bug fixes and not new features.

There will still be six-monthly releases of new minor versions, leading
to the next stable release every 2 to 3 years' time, but these minor
releases are not guaranteed to be compatible with one another.

I can't say I like it, but there we are.