[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 19 Sep 2018 20:22:43 +0000

Julian Foad wrote on Wed, 19 Sep 2018 18:11 +0100:
> There was some good discussion on IRC today about the rules for
> experimental APIs.
> http://colabti.org/irclogger/irclogger_log/svn-dev?date=2018-09-19
> I'll get ideas from this incorporated in the wiki page tomorrow.
> https://cwiki.apache.org/confluence/display/SVN/LTS+and+regular+releases

My notes from today are:

1. (see my email from earlier today about LTS promises not applying to
   experimental APIs)

2. Should we promise forward compatibility of experimental features
   within a minor line? Idea: Promise 'best effort' compatibility,
   i.e., we'll try not to break compatibility gratuitously, but we
   reserve the right to do so if needed, plus some promises on what
   the worst-case failure is (e.g., no bricking of apps due to runtime
   linker failure, no toasters growing arms). Compare how 1.A.0-rcN
   is not guaranteed to be forward-compatible with 1.A.0 GA, but often is.

3. Could we document on the wiki the _goals_ of the policy? E.g.,
   "Don't brick apps through runtime linker failing after", "Don't break
   ABI compatibility through incompatible changes to signatures", etc..
   Our promises should be sorted by scenario: downgrade within a minor
   line; upgrade within a minor line; upgrade across minor lines within
   a major line.

4. Question: Should we promise ABI backwards compatibility within a
   single minor line? In other words, would we permit new experimental
   functions to be added in a patch release 1.A.B where B>0?


Received on 2018-09-19 22:22:55 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.