Backwards compatibility before all else? [was Re: [PATCH v2] pager: migrate heavily-used extension into core]

[Bryan O'Sullivan]

On Sun, Feb 5, 2017 at 7:24 PM, Augie Fackler <raf at durin42.com> wrote:

>
> > I'm inclined to *not* add special code to see if the old pager extension
> has been disabled. That's achievable by disabling the pager instead. This
> would require a release note, of course (just in case anyone reads them).
>
> I’m conflicted here: I’ve been chasing my tail on a problem with emacs
> tramp-mode for months, and finally root-caused it to a missing flag in my
> pager settings for less, only triggered by emacs running hg over ssh. It
> was pretty baffling.
>
> On the other hand, it’s clearly the most-right choice to have the pager on
> as part of the recommended configuration. I’ve been using it (as an
> experiment) at work for over a year, and I’ve finally gotten used to it and
> (for the most part) like it.
>
> What do other people think?
>

Well, this is an interesting case of a bigger pattern.

To be honest, I think that the long-time insistence on (and acquiescence
to) backwards compatibility for every little aspect of behaviour for all
eternity has been extremely stifling. The fact that git users have thrived
despite a decade of occasional incompatible changes (including enabling
pager use by default) suggests that the compatibility-before-all
perspective wasn't ever really prioritised correctly in the first place.

I think that the community would do well to slightly loosen its standards
for breaking changes. Yes, such changes will cause occasional problems for
a small number of people, but the alternative of stagnation isn't super
appealing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170206/6202e3b3/attachment.html>