Which mercurial versions are worth testing against

[Augie Fackler]

> On Jan 7, 2017, at 2:40 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> 
> On Sat, Dec 5, 2015 at 12:27 PM, Marcin Kasperski <Marcin.Kasperski at mekk.waw.pl> wrote:
> 
> As I finally learned how to use tox to test against various mercurial
> versions (*), I contemplate … which versions to test against. Testing
> all of them takes a bit too long, so I'd prefer to stick a few most
> important versions.
> 
> The question is twofold:
> 
> - which mercurials are currently really used „in the wild” (distributed
>   by popular distros, frequently seen etc)
> 
> - which versions introduced most important api changes?
> 
> At Mozilla, our policy is to support up to 1 year's worth of releases (the past 4 versions) because supporting older versions is too much work given the various internal API changes. This inevitably causes problems for people using their distro's Mercurial package, as distros tend to stick with the Mercurial version initially released with the distro. So, in the system "bootstrap" tool we provide, we guide people away from their distro package if it is too old.
> 
> A few releases ago, extensions can now declare a "minimum hg version" attribute and Mercurial will refuse to load extensions if they aren't marked as compatible with the current Mercurial version. So as long as users have that Mercurial version and our extensions define the attribute, we have a forcing function to keep client Mercurial installs updated.
> 
> As for your specific questions, we don't really have data on version use. My guess would be the popular versions are what the popular distros are shipping.
> 
> As for "important api changes," it really depends what APIs you are using. Every release has some changes that impact someone. As an author of several extensions, I've found the internal API to be surprisingly stable given its lack of stability guarantees. I've seen a trend in the last few years where internal APIs are refactored to provide informal hook points to make the lives of extensions easier. This has cut down on the amount of function copying and excessive monkeypatching. And, if an extension needs a code refactor to work better/easier, we're generally receptive to that, as we want to encourage experimentation in extensions.
> 
> Generally speaking, if your extension lives "at the edges" or is only touching high-level APIs (like things in hg.py or are using uisetup() and reposetup()), things shouldn't be too bad. Things tend to break more often when you are hooked in at lower layers.

Yep. I think remotebranches has required maintenance less than once a year, and it’s almost entirely non-invasive. At the other end of the spectrum is hgsubversion, which monkeypatches nearly all the things and requires regular maintenance. What I’ve set down as my policy is basically this:

1) Always support most recent release, previous release, and whatever is in Ubuntu LTS.
2) Support other versions only when it’s easy.

Ubuntu LTS is a proxy for “the oldest hg users are likely to be running in practice” for me - and so far it’s worked remarkably well. You might also use something like debian stale as a proxy for that. So far, I’ve gotten relatively few complaints about supported versions of Mercurial.

Hope that helps!
Augie