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
