1.0 approaches

[Peter Arrenbrecht]

On Feb 8, 2008 8:57 AM, Brad Schick <schickb at gmail.com> wrote:
> On 2/7/2008 9:52 PM, Matt Mackall wrote:
> > On Thu, 2008-02-07 at 21:36 -0800, John D. Mitchell wrote:
> >
> >> On Feb 7, 2008 9:17 PM, Bela Babik <teki321 at gmail.com> wrote:
> >>
> >>>> In my opinion, named branches in their current form do more harm than good.
> >>>>
> >>> ...
> >>>
> >>>> I'd be inclined to discourage their use strongly in 1.0 (maybe relegating
> >>>>
> >>> I strongly disagree. It is true, that it is more like a dynamic
> >>> tag than a branch, but it helps to a lot.
> >>>
> >> Then changing the naming to make that reality clear would be okay to you?

I strongly second naming a thing for what it is. However, if the plan
is to bring named branches up to what people would expect of the name,
then renaming now might not be a good idea. Discouraging current use
would be better.

> >>
> >
> > The time for such non-backward-compatible changes has long since past so
> > there's not much point to this conversation.
> >
>
> How about moving the existing command to an extension that is off by
> default? Anyone who is currently using this feature successfully
> probably knows what they are doing and could easily re-enable for
> backwards compatibility. New users would be less likely to stumble into
> problems (and be more likely to read the details if they enable it).

Or maybe just introducing the new name and deprecating the old one a
little less harshly? For instance, by only showing it in `hg help
--debug`.

-peo