Re: API compatibility promises in light of biannual releases (was: Re: Intentions for 1.11 release timing)
From: Julian Foad <julianfoad_at_apache.org>
Date: Tue, 21 Aug 2018 16:19:29 +0100
Daniel Shahaf wrote on 2018-06-29:
A policy that forces new APIs to be set in stone at their first release is a hindrance. At the same time, it is important to follow a clear versioning specification. We currently seem to match Semantic Versioning http://semver.org although we don't explicitly reference it. This says the minor release number indicates backward-compatible additions and changes, and the major number must be incremented if we make incompatible changes. I don't think we want to be removing APIs and bumping the major number on our LTS releases.
> Or perhaps we just need to be more disciplined about properly marking APIs as
I don't think marking things as experimental is a very good approach when applied "ad hoc". It is easy to mark something as experimental initially and then never review and upgrade or remove it, leaving its users in limbo.
However, a process of marking all new APIs as experimental in regular releases, and ensuring we review them for LTS releases, might be a good way to satisfy both Semantic Versioning and experimental APIs.
That is my best suggestion.
-- - JulianReceived on 2018-08-21 17:19:37 CEST
This is an archived mail posted to the Subversion Dev mailing list.