API compatibility promises in light of biannual releases (was: Re: Intentions for 1.11 release timing)

Julian Foad wrote on Fri, Jun 22, 2018 at 14:26:53 +0100:
> Another angle on this: I interpret what we are doing as inserting extra
> mini-feature-releases into the existing cycle, rather than compressing the
> existing cycle to happen four times faster.

I wonder what our API compatibility promises would be in the new scheme.

In terms of the proposed scheme, we currently do only LTS releases, and once an
API appears in an LTS .0 release it will remain supported until the subsequent
major release, i.e., practically forever.

I assume our API current compatibility promises would apply unchanged to any
APIs that appear in LTS releases. However, I'm not sure we necessarily want to
offer the same promises to APIs that (first) appear in biannual releases,
because those APIs will have had less time to mature (in design / review /
deployment).

As an example, perhaps APIs new in a biannual release should only be supported
until the subsequent LTS release? Then, once an API makes its first appearance
in a biannual release, if it's a good API we include it in the subsequent LTS
and it's set in stone, but if needs some tweaks we aren't obliged to support
the original version forever.

Or perhaps we just need to be more disciplined about properly marking APIs as
"experimental" (doxygen "@experimental" annotations and SVN_EXPERIMENTAL
preprocessor annotations) when they are objectively not yet mature.

WDYT?

Cheers,

Daniel
Received on 2018-06-29 19:34:34 CEST