Re: how to determine oldest supported version of git

From: Jeff King <peff@peff.net>
Date: Feb 2, 2012, 19:49 UTC
Message-ID: <20120202194937.GB9246@sigill.intra.peff.net>
In-Reply-To: <20120202192124.GA19873@burratino>

On Thu, Feb 02, 2012 at 01:23:40PM -0600, Jonathan Nieder wrote:

Show 11 quoted lines

> However, in my experience people interested in product lifetimes more
> often mean "versions the vendor will respond to bug reports about"
> rather than "versions getting updates".  If you have discovered a bug
> in an old version of git, even if it is only a couple of major
> releases ago, a good debugging strategy is almost always to try with
> the newest release and see if it still exhibits the bug.  If you don't
> try that, people on this list might just try it themselves.  If it
> doesn't affect recent releases, I would not be surprised if people on
> this list do not necessarily care much.  One can more easily interest
> me at least by pointing out which regression is making it hard to
> upgrade instead.

Agreed. It is very annoying to have somebody report a bug, I (or another dev) spends time trying to reproduce, and then we find out that it was actually fixed a year ago.

However, I am much happier if a submitter does that leg-work themselves, and posts to the list something like:

  I am using version a.b.c. It has bug $FOO, which was fixed by $COMMIT
  and released in d.e.f [or even "I tried d.e.f and it does not exhibit
  the bug"]. This bug fix should get cherry-picked back to a.b.c,
  because {it is more important than usual for reason X, upgrading past
  a.b.c is not feasible for reason Y, etc}.

Nobody wastes time tracking down the already-fixed bug, and it's relatively easy to decide whether the cherry-pick is worth the effort based on the reasoning given.

I know not everybody is capable of complex bisection or writing a succinct test case. But they can at least try to reproduce with the latest version and convert "there's a bug in git" to "there's a bug in this old version of git".

-Peff