Am Donnerstag, 27. November 2014, 16:50:12 schrieb Neil Williams: > On Thu, 27 Nov 2014 16:24:12 +0100 > > Matthias Urlichs <matthias@urlichs.de> wrote: > > Hi, > > > > Neil Williams: > > > By having separate source packages, a stable API becomes mandatory. > > > > You're correct in that it is easier to keep an API stable when you > > have separate repositories. But that is not a hard requirement. There > > are other ways to keep APIs stable. Like, for instance, publishing a > > specification (once you _have_ a stable API) and sticking to that. > > Programmers are lazy, we all know this. If a #include "local.h" will > fix a scoping problem, someone will do it. Keeping to an external > specification intended for "others" without rigorous code review is no > fun either. > > So, in practical terms, separate source repositories become all but > essential. > > > But when things are in flux and you're in the process of figuring out > > what the API should look like in the first place, having multiple > > places to update, which can and will get out of sync, is no fun. > > It can also be when this approach is actually of the most value as it > protects against regressions and complex failures. A stable API > protects *against* having to update multiple places at the same time - > you add functionality without removing the old functionality, so the > external source packages can migrate in their own sweet time. Being out > of sync is only a problem if the API is not sufficiently stable or > comprehensive. We have symbols files for this kind of thing - at least > in some languages... ;-) Fill the deprecated code with warnings if you > have to but keep to the API. Fix the components in the order of the > severity of the problems with the old code as used in that component. > > The whole point of a stable API is that backwards and forwards > compatibility is retained until such time as there are no extensions or > components using that support - at which time the base library goes for > a SONAME transition and everyone is happy. Deprecate old functionality > without removing the functions, add new functions, migrate through the > components gradually. Simple. > > Start with the API. It's not as if a package which is considered ready > for release into the stable suite of multiple distributions can > possibly be in such a state of flux that an API cannot be constructed. > If it is, the package is release-critical buggy by definition. Broken by > design (or lack of). > > Yes, in the first proof of concept days when maybe you aren't even sure > which language(s) or build system to use and it only exists on your own > system or a personal VCS repo - then there can be sufficient flux to > prevent an API being designed. However, packages in Debian are > generally quite a long way on from that point - especially if those > packages are to be considered as part of a stable distribution release. > > Let's move away from upstreams who make it hard to put their software > into a collection in a flexible and stable manner. Push back and > explain the benefits of small, compartmentalised source packages and a > stable API. It will make the work of the release team easier and it > will make it easier for developers to improve the code more generally. +1 Technical convenience is not enough. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.