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?
Cheers,
Daniel
Received on 2018-09-19 22:22:55 CEST