Re: Git v2.20.1 EOS date

Nicolas MAFFRE <nicolas.maffre.external@airbus.com> writes:

As we clearly describe in our COPYING document, there is no warranty as far as the project is concerned, so "End of support" is a foreign concent on this list.

When a bug is found, we try to fix it in a way that can be merged to the oldest released version with the bug, but we do not usually do the backporting ourselves all the way down to an ancient version.

 * For a normal bug that does not require an embargoed security fix,
   we apply a fix to the tip of the tree that is preparing for the
   next feature release, and we often apply the same fix to the
   maintenance track for the most recent feature release (as of
   today, the 'master' branch is working towards 2.38, and the most
   recent maintenance track is 2.37.x) ourselves and cut a
   maintenance release (the last one was 2.37.1 so a follow-up
   maintenance release might be 2.37.2).  But the maintenance track
   older by two generations or more are usually untouched.

 * For a security sensitive bug, members of a separate security
   mailing list works behind closed doors to assess the issue to
   decide which maintenance tracks should receive a fix, prepare the
   fixes for them and propagate up to the tip of the tree.  The cut
   off point depends on the severity of the bug, but typically the
   shelf life of a Git release is less than roughly 3 years since
   the first feature release of the track.  E.g. Git 2.30.0 was
   released on 2020-12-27, and the maintenance track 2.30.x did get
   the most recent security update, but the maintenance track 2.29.x
   (2.29.0 was on 2020-10-19) and older did not.

A bugfix patch (e.g. the changes found by "git log v2.36.0..v2.36.2" are the fixes we made after we started working toward 2.37 or later and applied to 2.36.x maintenance track) can often be cherry-picked to older maintenance tracks [*], because the fixes are often designed that way, but as explained above, we usually do not do the cherry-picking ourselves. You'd just need to do that work or pay somebody else to do that for you, if you are not "following along" with the most recent releases.

But the distributor of your operating system may offer extended support. I do not recall 2.20 being of any significance, so I do not see why any distributor find a particular interest in giving it a long term support, as opposed to picking say 2.19 or 2.23, though.

[Footnote]

 * Sometimes a fix to an issue that originates in ancient version
   may only be applicable to reasonably new versions, as the code
   evolves and we may do things in morally-equivalent-but-different
   ways.  I as the maintainer try to rein our developers in before
   they make changes that are not necessary "while at it" to
   minimize such code drift, but I am not always successful.