On 24.11.2016 09:27, Daniel Pocock wrote: > 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. [...] > 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. There have been precedents of stable updates to address those issues. But there is also a natural limit of what can reasonably be addressed in a stable update. That's where it gets really tricky how to cope with the changing environment around us. On example would be clamav which gets new upstream versions to cope with newly issued signatures downloaded from the Internet that make use of features that are not available in a year-old version. Of course the larger the update, the larger the chance that a regression hits (which had happened with clamav before). So if you, as an upstream maintainer, have a change that is needed for compatibility with changes in network APIs and the change is reviewable by humans, a stable update could be possible. It's still on a case-by-case basis, so you would need to ask and the Release Team cannot approve what they do not know about. Kind regards Philipp Kern
Attachment:
signature.asc
Description: OpenPGP digital signature