[PATCH 2 of 2 RFC] dispatch: try and identify third-party extensions as sources of tracebacks

[Brendan Cully]

On Thursday, 28 July 2011 at 18:08, Matt Mackall wrote:
> On Mon, 2011-07-25 at 21:55 -0500, Augie Fackler wrote:
> > # HG changeset patch
> > # User Augie Fackler <durin42 at gmail.com>
> > # Date 1311622871 18000
> > # Node ID 245f5bbe00788d00ed4e6d6bd27a22c5163365f1
> > # Parent  e59468fa239985828ce199d3ae8cb1768987525c
> > dispatch: try and identify third-party extensions as sources of tracebacks
> 
> For anyone who's missed the discussion surrounding this, the basic idea
> is that every extension has a list like this:
> 
> testedwith = ['1.8', '1.9', '2.0']
> 
> and extensions.py has:
> 
> apiver = '2.0'
> 
> When a traceback happens, we check each extensions to see if:
> 
> a) it appears in the traceback

that's my patch (though I'm sure it doesn't catch all the ways an
extension can cause an exception)

> b) apiver doesn't appear in its testedwith list

and that's Augie's.

I agree this is how they should be combined :)

I'd just like to point out that explicit versioning is really only
useful for whitelisting. Many extensions will continue to work with
newer versions of mercurial for a long time (this is why we've been
able to go this long without any kind of API or versioning).

I'd also emphasize that my patch isn't guaranteeing which of the
extensions appearing in the traceback is actually at fault. It's just
using the heuristic that the one closest to the exception in the stack
is probably it -- but it's probably not hard to construct cases where
this is untrue.

> ..and then point the finger of blame at it.
> 
> We had some more discussion about this on IRC, I want to try to clarify
> the use-cases I care about.
> 
> 1)
> 
> User has Mercurial 2.0 and hg-foo last updated for 1.9. hg-foo triggers
> breakage. We'd like to find hg-foo in the traceback and let the user
> know it's not been tested with Mercurial 2.0.
> 
> This case is pretty straightforward and is the bulk of our current
> issues in this area.
> 
> 2)
> 
> Tester has a _pre-release_ version of Mercurial 2.0 and hg-foo last
> updated for 1.9. They're testing during the 2.0 code freeze call for
> testing and the internal API is effectively locked down. Again, we want
> them to get pointed to hg-foo for support, and hopefully trigger hg-foo
> to make sure they're release-ready before the release date.
> 
> I think it's important this this happens. We want to get to a point
> where we have sufficient pre-release testing that post-release users
> will in fact be able to download working updates.
> 
> 3)
> 
> User has a default branch checkout of Mercurial post-1.9 and hg-foo last
> updated for 1.9. The internal API may change one or more times between
> now and the release. Ideally we'd like hg-foo devs to get an early
> heads-up that things have changed so they don't have to scramble during
> the code freeze.

Personally I'm not sure versioning matters for this kind of
scramble. Either the extension devs are testing against a prerelease
or they aren't, and all that really matters is whether the code is
compatible, not whether the version numbers match. I think it makes
just as much sense to not version the API, and just tag the extensions
with the hg versions they've tested against after those hg versions
have been released.

In short, extension authors should start testing when code freeze
happens, and I don't think a version field in the prerelease codebase
affects that much.

> So at some point, we need to say "this is the 2.0 API". The problem is
> case 3: if we mark the API as "2.0" on the default branch when we
> release 1.9, hg foo might only update once after that and we might get
> false negatives in case (2). If we wait until the freeze to mark the
> API, we may instead get false negatives in case (3) and lose the
> opportunity to update the extension early.
>