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
