Re: Gtk+4.0

[Davin McCall <davmac davmac org>]

On 12/09/16 19:35, philip chimento gmail com wrote:

I won't have time to reply to this and Peter's new messages just now; but Davin, I'm curious to know if the plan from [1] addressed some of your concerns.

[1] https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

To a large degree, yes. The new plan seems much more sensible, in my view, than the original proposal. Having a distinct numbering scheme for development releases is important. I think removing deprecated API when incrementing the major version is acceptable, though I would still argue against doing so in cases where it does not create a clear maintenance burden.

(Put it this way: can the old API be implemented in terms of the new? If so, do it once and you never need touch it again. If not, does this indicate a shortcoming of the new API?).

For the most part, though, I think the plan as outlined will alleviate the concerns of many developers.

In lieu of a better reply, one thing that I'm reading from the above is that it might be good to do a GTK blog post on what our best practices are for API design. We do have them; the API doesn't just emerge from the code; but it would be a really great idea to illuminate what goes on.

I'm glad to hear that, and I for one would be interested in reading such a blog post.

For what it's worth, the current desires to break API I would say mostly stem from needing to get rid of API that was designed in a different era, and is holding things back by making too many assumptions about the underlying tech stack.

Yes, I certainly understand the need, on occasion, to remove or incompatibly change API that cannot feasibly be made to work with new developments. I think that there does need to be awareness, however, that changing API creates a burden elsewhere (in external projects that use the API). Removing deprecated API may sometimes be necessary, but if it is done over-zealously it forces other projects to continuously track API changes or choose instead to stick with an old, stable API which (no matter how long-term its support is) will eventually be obsolescent. Perhaps the latter is inevitable for projects that are not afforded the luxury of continuous ongoing maintenance, but it is still desirable to postpone it where possible. In my view, good API design practice tends to produce future-proof APIs (which can made to work even with unforeseen technology changes in the future). Having said that, I do realise it is not always possible to produce the perfect API the first time around.

Regards,
Davin