Am Samstag, 29. November 2014, 10:49:34 schrieb Martin Steigerwald: > Am Donnerstag, 27. November 2014, 16:50:12 schrieb Neil Williams: > > On Thu, 27 Nov 2014 16:24:12 +0100 > > > > Matthias Urlichs <matth...@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.
In my oppinion that is. There are different oppions. All of them are valid. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
signature.asc
Description: This is a digitally signed message part.
