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. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpbFYH1j5UWR.pgp
Description: OpenPGP digital signature