[PATCH 6 of 6 RFC] extensions: show deprecation warning for the use of cmdutil.command

[Yuya Nishihara]

On Mon, 15 May 2017 13:08:15 -0400, Augie Fackler wrote:
> On Sun, May 14, 2017 at 12:11:53PM +0900, Yuya Nishihara wrote:
> > On Sat, 13 May 2017 11:00:02 -0700, Gregory Szorc wrote:
> > > On Sat, May 13, 2017 at 2:57 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> > > > # HG changeset patch
> > > > # User Yuya Nishihara <yuya at tcha.org>
> > > > # Date 1452349492 -32400
> > > > #      Sat Jan 09 23:24:52 2016 +0900
> > > > # Node ID 1b5d23403828e246d89816c4826a25a7de586cee
> > > > # Parent  484b2808830a2a390d9e1128c6e88d9249097fa6
> > > > extensions: show deprecation warning for the use of cmdutil.command
> > > >
> > > > This is RFC. Do we really want to remove cmdutil.command?
> > > >
> > >
> > > I'm in favor of this. But I think it should be deprecated for multiple
> > > releases to give extensions time to transition. The reason is this is one
> > > of the oldest and most used APIs in extensions. When we remove it, we'll
> > > break a lot of extensions. But simply marking it as deprecated has no
> > > impact unless developer warnings are on. So it shouldn't be too
> > > controversial to start the process.
> >
> > How about setting the target to 4.2 + 2years = 5.0 for now? I don't want
> > to add version=None support to ui.deprecwarn() API because it would be
> > so convenient for developers to abuse.
> 
> 2 years is a stinking long time. Could we go with 4.6 at the latest?
> 
> (Agree that this is pretty high impact churn that merits some special
> attention, but I'm skeptical that there will be a difference between a
> year and two years for the deprecation window.)

Sure. I'll send V2 with version='4.6' when the first half get queued. We
can extend the limit if that really matters.