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
