Web lists-archives.com

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@xxxxxxxxxxx>
> 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

gtk-devel-list mailing list