In defense of qnext and qtop

[Peter Williams]

On 14/09/09 17:11, Thomas Arendsen Hein wrote:
> * Peter Williams<pwil3058 at bigpond.net.au>  [20090912 15:50]:
>> On 12/09/09 20:13, Dirkjan Ochtman wrote:
>>> On 11/09/2009 17:24, Thomas Arendsen Hein wrote:
>>>> This would be enough for me, too.
>>>>
>>>> Additionally we should follow our own guidelines:
>>>>
>>>> http://mercurial.selenic.com/wiki/CompatibilityRules#Commands says:
>>>> "Removing a feature requires a deprecation period of at least one
>>>>     major release"
>>>>
>>>> http://mercurial.selenic.com/wiki/CompatibilityRules#Extensions says:
>>>> "Extensions that are shipped in hgext/ follow the same compatibility
>>>>     rules as core code"
>>>>
>>>> So add --prev, --next, --top (and maybe --applied and --unapplied)
>>>> to qseries, restore qprev and friends, but mark them as deprecated.
>>>>
>>>> Remove qprev and friends in the following major release.
>>>
>>> Sounds great to me. Anyone wants to argue something else?
>>
>> Don't forget to get the book reprinted.  I.e. the interface is already
>> published in the great outdoors and it's too late to change it (except
>> by addition).
>
> Maybe keep the old commands longer as e.g. "debugqtop|qtop" so they
> do not show in default help and tab completion.
> (and remove them for Mercurial 2.0 and the next release of the book)
>
> Or just add them as an alias in a default hgrc?

Or in a global configuration file.

>
> But all these ways have a common first step:
> - add qseries options
> - mark old commands as deprecated
>
> So I think djc can already start with this one while this discussion
> continues.

I've got no problem with adding features but I do think it's important 
that the interface as described in the book continues to work "out of 
the box".  Otherwise Mercurial's reputation will nose dive.

Peter
-- 
Peter Williams                                   pwil3058 at bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce