Re: New versioning scheme in gtkmm? In glibmm?

[Murray Cumming <murrayc murrayc com>]

On Di, 2016-09-27 at 01:27 +0100, Chris Vine wrote:
> 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-stabilit
> > > y-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.

Yes. I don't think that's workable, at least not with a time-based
release schedule that people believe in.

I can't see how they will avoid adding API in stable releases too.

So in the end, I don't see how much will change, other than that we
will now have uncertainty about what and when things should, and will,
happen.

I'm not a fan, clearly. It looks like people have got so used to having
time-based releases that they forgot why they need them - a bit like
thinking that diseases aren't serious because we are used to having
vaccinations. But I'm also not heavily involved, so my opinion
shouldn't count for much.

>  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,

Of course, the answer to that would be just to document things
properly.

> 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.

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