On Wed, 2017-05-03 at 18:15 -0400, Matthias Clasen wrote: > On Wed, May 3, 2017 at 2:55 PM, Murray Cumming <murr...@murrayc.com> > wrote: > > Will there absolutely positively never be any GTK+ 3.23/24 > > releases? > > > > After all these years of not adding API, or deprecating API, in > > micro > > releases, I feel very uneasy about doing that in gtkmm 3.22.* just > > because GTK+ seems to be doing it. > > No plans for a 3.24, no. I don't think there is much of a problem > with adding deprecations - they are really a tool to help people > prepare for the jump to the next version. If you want to stick with > 3.22.x, there is no reason to chase deprecations.
Yes, deprecations are indeed far less of an issue that API additions. I'd still rather avoid them in a micro release, so it's clearer when the API was deprecated. > As for new API, we have been pretty careful so far, and only allowed > some very minor additions in 3.22.x. Any examples you are thinking of > ? Sorry. Yes, you are right. I was sure we'd found some API additions, but it was just deprecations. > > But if there will never be a GTK+ 3.24, we could have a gtkmm 3.24 > > that > > adds and deprecates API without causing too much confusion in the > > future. > > I'm afraid that a gtkmm 3.24 that is based on gtk+ 3.22 would cause > quite a bit of confusion. We have at least one other API (but not ABI) change (to our Gtk::Box::pack_start() that we'd like to make in a gtkmm 3.24 release, regardless of any GTK+ API additions, to ease porting to gtkmm 4, though we haven't decided that yet. We can't do that in a gtkmm 2.22.x release without upsetting people because of breaking builds. I had hoped that a GTK+ 3.24 might exist to solve that problem for us. Murray Cumming murr...@murrayc.com www.murrayc.com _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
