On 12/09/16 19:35, philip.chime...@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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
