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

Kevin Bullock kbullock+mercurial at ringworld.org
Mon Feb 6 17:41:04 EST 2017


> On Feb 6, 2017, at 14:00, Bryan O'Sullivan <bos at serpentine.com> wrote:
> 
> 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.

I for one still generally agree with the strong emphasis we've always placed on backward compatibility. I think there's a pretty well-established, if subtle, set of distinctions that we've made about different kinds of backward compatibility, though. Some of them have been more strongly guarded than others, so we should be clear on what we're discussing if we want to change our approach.

First, there's compatibility of on-disk repositories and the wire protocol: new versions should always be able to interact with old repos. This is one of the strongest guarantees we maintain.

Second, there's stability of the command-line output. The degree to which this is guarded depends on the command, namely on how likely it is to be used in everyone's janky scripts.

And so on, for a bunch more categories that are listed on <https://www.mercurial-scm.org/wiki/CompatibilityRules> and more that probably aren't.

Anyway, these things often ultimately come down to a case-by-case judgement call, and I suspect that the current reviewers will tend to fall a bit less often on the side of keeping things static than Matt did. But I think the case still needs to be made clearly as to the benefit vs. potential for breakage of any particular change.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list