Re: GTK+ 3.24?

On Wed, 2017-05-03 at 18:15 -0400, Matthias Clasen wrote:
On Wed, May 3, 2017 at 2:55 PM, Murray Cumming <murrayc murrayc com>
Will there absolutely positively never be any GTK+ 3.23/24

After all these years of not adding API, or deprecating API, in
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
adds and deprecates API without causing too much confusion in the

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
murrayc murrayc com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]