Nicolas MAFFRE <nicolas.maffre.external@xxxxxxxxxx> writes: > I'm working on a project that uses Git v2.20.1 and I need to know > if there is an "End of support" date for this version of the software Git ? 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.
