Deploying registrar configs in a BC safe way

[Gregory Szorc]

> On Oct 24, 2017, at 10:25, Durham Goode <durham at fb.com> wrote:
> 
> I've been trying to update our extensions to support the new registrar class, and one thing I've noticed is that it's not really possible to have code that works with old versions of mercurial and new versions of mercurial at the same time, without having devel warnings. I can easily stub out the registration logic if the registrar module doesn't exist, but I can't leave the default values on the actual config accessor lines, which old mercurial versions would need.
> 
> For now I'm just updating our extensions to only work with new mercurial, but if someone tries to use them with an older version it will cause subtle failures as the default configs will be different.
> 
> I tried to think of some way to fix this, like by leaving the defaults on the config access line, but ignoring it somehow, but that sounds funky. Thoughts on how to fix this?

How about making registrar instances on extensions have different behavior from core? e.g.

* No devel warnings for e.g. missing default values for a few releases
* Arguments to control which devel warnings are issued