Re: First deprecate APIs and then remove them in the next major version

[Emmanuele Bassi <ebassi gmail com>]

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.

I'm having major flashbacks from the same discussions we had at Gran
Canaria, when we planned 3.0 — with people asking for releasing 3.0
only with sealed data structures and without deprecated API.

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.

If we just removed deprecated API without adding any new feature,
there would be no incentive whatsoever to port applications to a new
major version, which will result in an untested API that we cannot
change until the next major release cycle.

That's why we released the 9x snapshots; to give us, and application
developers, time to iterate over the API.

The problem is that we're trying to fix almost two decaded of hacks
and cruft piled on top of each other, and any new feature comes with
its own set of removals.

> So, that's it, I think when GTK+ 4.0 will be released, if it is still
> developed in the same way, developers will have a really bad surprise
> when trying to port their code.

The reason why we're doing the 9x snapshots — the reason we change the
whole release management process and model — is because we will *not*
be developing 4.x (and 5.x, and 6.x) the same way we developed 3.x.

The 9x snapshots are the first cycles of 3.x, writ large. We give up
API compatibility during that period in order to have a firmer n.0
release, and later minor cycles, until we open the tree for the n+1
development.

Yes: the delta between 3.x and 4.x is going to be large — at least, if
you're implementing widgets. It's not something we expect this to
happen with every major release; we don't really expect to change the
way we render everything, or to change the input subsystem, every
major cycle.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]