[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: API review for 1.11; do we need to mark new APIs as experimental?

From: Greg Stein <gstein_at_gmail.com>
Date: Sat, 15 Sep 2018 08:48:49 -0500

On Thu, Sep 13, 2018 at 10:24 AM Branko Čibej <brane_at_apache.org> wrote:

> On 13.09.2018 17:11, Julian Foad wrote:
> > Julian Foad wrote:
> >> [...] Are we saying now
> >> that they need not be specifically marked if we feel they are pretty
> >> safe? If we say that, then marking specific APIs as "experimental" in a
> >> regular release signifies only that we consider them more experimental
> >> (less stable) than others.
> >>
> >> That might be fine. Anyone developing against a regular release is
> >> necessarily developing against new (experimental) APIs, so maybe no
> >> explicit warning mechanism is necessary.
> > I have gone ahead with producing a release candidate 1.11.0-rc1 with
> things just as they are. It currently seems OK to me. If we decide we need
> to change this, we can.
>
>
> I've been thinking about this idea of having different compatibility
> rules for LTS and regular releases. For 18 years now we've promised and
> maintained fairly simple rules of API and ABI compatibility; so much so
> that they're implied in and used by our own code. I've come to the
> conclusion that changing these rules just because we're changing how
> many releases we support would be a very bad idea indeed.
>

Being absent from that discussion ... oh geez.

No no no... I agree with Brane above. It is confusing, and if people
mistakenly mix/match releases things will Just Break. Mysteriously. And
horribly. And possibly data-destructively. And in 18 years, we've never
allowed for API/ABI breakage. Never.

We've been able to be hard-core with our compatibility guarantees for 18
years. Why stop?

-g
Received on 2018-09-15 15:49:21 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.