Re: API review for 1.11; do we need to mark new APIs as experimental?

Daniel Shahaf wrote:
> Julian Foad wrote:
>> We recently decided that only APIs released in an LTS release will be
>> subject to our compatibility guarantees. As 1.11 is not an LTS release,
>> the above APIs will not be subject to those guarantees (until they
>> appear in an LTS).
>>
>> Do we need to do anything in the source code to emphasize that, for the
>> ones that are not already marked 'experimental'? If so, what? Mark them
>> 'experimental' in addition to their existing annotations (which probably
>> would mean we'd want to turn off the warnings about use of experimental
>> APIs in our own builds), or something else?
>
> I'm not sure all of these APIs need to be marked experimental. For
> example, svn_client_layout_list() is new functionality that we might not
> want to support forever, but the 'pretty_print_mergeinfo' change sounds
> pretty safe.

How do you square that with the proposal in the thread "API compatibility promises in light of biannual releases" where you replied "+1" to the following?

> 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.

There, the proposal was that *all* new APIs (which I would assume includes revved ones) should be regarded as experimental and marked as such until "blessed" by appearing in an LTS release. 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.

-- 
- Julian