[PATCH] extensions: formalize concept of experimental extensions

[Gregory Szorc]

On Tue, Mar 21, 2017 at 10:59 AM, Ryan McElroy <rm at fb.com> wrote:

> On 3/15/17 1:10 PM, Yuya Nishihara wrote:
>
>> On Tue, 14 Mar 2017 08:45:44 -0700, Jun Wu wrote:
>>
>>> Excerpts from Yuya Nishihara's message of 2017-03-13 19:02:06 -0700:
>>>
>>>> How about <name>:allowbeta = True ?
>>>>
>>> Old clients will try to load "True" as an extension.
>>>
>> Ah, good catch.
>>
>>
> So it looks like this approach won't work -- do we have other suggestions,
> though? I'd like to see this functionality exist someday so we can move
> some mostly-stabilized stuff into core.
>
> What about a new section, "[betaextensions]" or "[extensions-beta]" ?
>
> Extensions listed in [extensions-beta] will load whether they are beta or
> stable, but if they are in [extensions], they will only load if "stable"?
>
> Thoughts?
>

That definitely works without concerns about legacy client behavior. I not
thrilled about introducing a new config section. But if we have to do it,
we have to do it.

I like "[extensions:beta]" for "[extensions-beta]" for readability. (I'm
not a fan of nameswithoutpunctuation because they are often difficult to
comprehend, especially for non-English speakers. I feel that
nameswithoutpunctuation undermine the "easy and intuitive interface" claim
on www.mercurial-scm.org.)

FWIW, I think it might be a good practice on any new config section to
iterate keys without sub-options (strings without ":"). That way, future
versions can introduce sub-options to tweak per-item behavior without
having to worry about backwards compatibility.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170321/0789ffc9/attachment.html>