[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: First deprecate APIs and then remove them in the next major version
From:       Nicolas Dufresne <nicolas () ndufresne ! ca>
Date:       2017-12-13 17:39:58
Message-ID: 1513186798.26958.31.camel () ndufresne ! ca
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Le mercredi 13 décembre 2017 à 17:34 +0100, Christian Schoenebeck a
écrit :
> > On 13 December 2017 at 12:05, Sébastien Wilmet <swilmet@gnome.org> wrote:
> > > Ideally, a new major version of a library should only remove deprecated
> > > APIs.
> > 
> > The short answer is: that's not how library development works, unless
> > you have a small enough library whose API is inconsequential, or it's
> > used only by a handful of projects. GTK is neither.
> 
> The most popular application level frameworks i.e. from Apple, Microsoft, Qt, 
> etc. are actually all handling it as expected by application developers; that 
> is they usually deprecate old APIs and retain them for many years before they 
> eventually (if at all) remove them one day. It is rare that they remove APIs 
> without deprecating them first, and in such rare cases there are "usually" 
> profound reasons like security aspects (or -cough- "product policies").

I don't think that applies to QT3/4/5 and then big jump, QML. GTK 4 is
the second major rework of GTK, it breaks stuff, and that's how we
modernize libraries. GTK3 is not going to be removed from servers when
GTK3 comes out, neither the .9 release means that stable 3.X is dead.

We did the same move with GStreamer, it's painful, but to progress,
it's needed.

Nicolas
["signature.asc" (application/pgp-signature)]

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


[prev in list] [next in list] [prev in thread] [next in thread]