Re: GTK+ 3.24?

[Murray Cumming <murrayc murrayc com>]

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