Deploying registrar configs in a BC safe way

Yuya Nishihara yuya at tcha.org
Wed Oct 25 07:51:52 EDT 2017


On Tue, 24 Oct 2017 18:49:50 -0700, Gregory Szorc wrote:
> > 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.

I made all extension-specific configs "dynamic", and add explicit defaults
to ui.config*() calls instead.

https://bitbucket.org/yuja/hgext-textful/commits/1f284a246abb

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

Or,

* No devel warnings for the "ui.config()" default matching the "configitem"
  default, which should be harmless


More information about the Mercurial-devel mailing list