Which mercurial versions are worth testing against

[Gregory Szorc]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20170107/2f0dadb9/attachment-0002.html>