[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Letsencrypt-devel] Certbot in Debian Stretch




On 24/11/16 00:06, Peter Eckersley wrote:

> So Let's Encrypt definitely wants to get to a place where we have some very
> stable APIs for other people to code against. We're trying to do that with the
> Certbot command line itself, working hard to ensure that if people upgrade, it
> doesn't break scripts they might have written around the client. And in the
> long run, I suspect ACME will mature and stabilise too.  But it's especially
> tricky to expect long-run-future-compatibility from a service that's only been
> online for a year.
> 


Personally, I haven't seen a strong response to this challenge in any
previous discussions like this.  It has been raised before.

The rational for the freeze is that we don't want things to break after
a release is declared stable.

For those things that use a networked API, however, they break anyway.
Therefore, the logic we apply to the terms "freeze" and "stable" becomes
very shaky.  Sure, if somebody runs their own locally hosted version of
the service (e.g. boulder), they may be happy to have the same client
forever as well.  These cases are probably very limited though.

The fact that a project tries to keep the command line API (and maybe
API and ABI) 100% backwards compatible is a very good thing, as you
point out, people script a lot of this stuff.

As well as the real-time communication projects I mentioned in my
earlier reply, this type of situation also arises with a whole range of
other network APIs these days, for example, the MusicBrainz[1] API used
by libmusicbrainz[2] for various music players or the libphonenumber[3]
library that tracks telephone area codes and country codes.

Debian's users, including developers, often want the benefits of these
services but the upstream developers of these services, especially if
they are volunteers, are often unable to keep up with all the
obligations for making stable release updates on every distribution.

Regards,

Daniel


1. https://musicbrainz.org/
2. https://packages.qa.debian.org/libm/libmusicbrainz5.html
3. https://packages.qa.debian.org/libp/libphonenumber.html


Reply to: