On 13.09.2018 17:11, Julian Foad wrote:
> Julian Foad wrote:
>> [...] Are we saying now
>> that they need not be specifically marked if we feel they are pretty
>> safe? If we say that, then marking specific APIs as "experimental" in a
>> regular release signifies only that we consider them more experimental
>> (less stable) than others.
>>
>> That might be fine. Anyone developing against a regular release is
>> necessarily developing against new (experimental) APIs, so maybe no
>> explicit warning mechanism is necessary.
> I have gone ahead with producing a release candidate 1.11.0-rc1 with things just as they are. It currently seems OK to me. If we decide we need to change this, we can.
I've been thinking about this idea of having different compatibility
rules for LTS and regular releases. For 18 years now we've promised and
maintained fairly simple rules of API and ABI compatibility; so much so
that they're implied in and used by our own code. I've come to the
conclusion that changing these rules just because we're changing how
many releases we support would be a very bad idea indeed.
Furthermore, the "experimental" designator should be used only for APIs
that, for one reason or another, cannot be private, yet we know that
we're not prepared to support them yet. Saying that everything in a
regular release is experimental would just sow confusion; it would tell
users not to rely on the bug fixes and new features in those releases.
The fact that the experimental designation currently isn't visible at
the ABI level is a separate problem and we shouldn't conflate it with
the meaning of a released API.
-- Brane
Received on 2018-09-13 17:24:17 CEST