On Di, 2016-09-27 at 01:27 +0100, Chris Vine wrote: > On Mon, 26 Sep 2016 22:26:01 +0200 > Murray Cumming <murr...@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 murr...@murrayc.com www.murrayc.com _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
