Re: how to determine oldest supported version of git

[Jonathan Nieder <jrnieder@gmail.com>]

Junio C Hamano wrote:

> But think again, with the intimate knowledge of how these bugfix topics
> are merged down to older maintenance tracks.
[...]
> But nobody in the development community rebuilds 'maint' every time it is
> updated and runs the result as his or her primary production version. Even
> I do not do that (remember, I run 'next'). I only build and run full test
> suite. Older maintenance tracks are worse. I do not think anybody runs
> them before they are tagged and released.

I can offer one data point.  In the context of Debian sid, Gerrit and
I do test each version in daily work before uploading it.  I generally
build from and test whatever track is going to be used for the next
upload (usually plus a few extra features I am interested in for
private use) a little while before the release, to be prepared.
Anders sometimes uploads to the Ubuntu PPA which brings more testers.
After the upload, users running "sid" test for about a week before
even more users running "testing" get to take a look at it and test
for the sake of later users who will run "stable".

So little bugs get discovered, with time to fix them.

Even with this, the extra time to migrate from 1.7.6 to 1.7.7, for
example, was very helpful in the context of Debian sid.  Like it or
not, new features *do* come with minor regressions, and it helps the
sanity of a package maintainer to not have to suffer people who did
not request a bleeding-edge release complaining about regressions
until there has been time to fix them.

Of course, this has nothing to do with Debian stable, which is an
orthogonal story.  I'll discuss that below.

[...]
>  * At that point, old 'maint' and 1.7.9.X track cease to receive updates,
>    as there is no point maintaining them. It only encourages distros to
>    stay behind, adding unnecesary maintenance burden to us.

If you are thinking of distros like Debian stable, then that is just
wishful thinking.  Dropping support for old releases does not have any
effect except to cause patches to be missed there.  (See iceweasel and
chromium-browser for examples where using the version in Debian stable
is something I would usually not recommend.)

This may seem weird, but keep in mind that people like you and me are
not the target audience for the git package in Debian stable.  We use
git heavily.  If I am on a machine running stable or RHEL, I will
build a private copy of git in $HOME or ask the sysadmin to install a
more recent git as the first thing I do.

The reason that packages go into Debian stable and then just _don't
change_ is that the target users are not using those packages heavily.
If a new feature (e.g., "signatures from tags get incorporated into
the merge commit from pulling them") causes a regression (e.g., "the
script I used to run every week that pulls my favorite software
package and builds it just stopped working"), then these people get
zero benefit, for a sizable cost.

Though that's a digression.  The relevant detail to mention here is
that there is real demand on downstreams to continue to maintain
packages without adding new features.  They will help to maintain
old releases if you want.  If we want to influence that maintainance,
for example to ensure security bugs are fixed correctly and in the
same way everywhere, a good way is to keep a maintenance branch.

Hoping that clarifies a little.
Jonathan