* Re: Git v2.20.1 EOS date
2022-08-02 8:34 Git v2.20.1 EOS date Nicolas MAFFRE
@ 2022-08-02 9:26 ` Ævar Arnfjörð Bjarmason
2022-08-02 16:12 ` Junio C Hamano
1 sibling, 0 replies; 3+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-08-02 9:26 UTC (permalink / raw)
To: Nicolas MAFFRE; +Cc: git
On Tue, Aug 02 2022, Nicolas MAFFRE wrote:
> Hello,
>
> 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 ?
Yes and no, for v2.20.* it was probably sometime around 2 years ago (see
below).
The Git project doesn't really do LTS or active support for anything
except the current or recent release(s), if there are issues discovered
in older releases they're fixed in newer ones, not in older "maintenance
tracks".
For bugs discovered in older releases they'll almost always only be
fixed in the code that'll become the next release.
For security fixes we do change some older releases, but usually only
the ones from the last 1-2 years. E.g. there was a security release
recently which included point-releases for versions as old as 2.30.*:
https://lore.kernel.org/git/xmqqv8s2fefi.fsf@gitster.g/; So that "2
years" above is just an inference of mine, judging from the last
security release.
How long that Window is is up to Junio's discretion, you can find some
others past such releases at:
https://lore.kernel.org/git/?q=s%3AANNOUNCE+s%3A%22and+others%22+f%3Agitster%40pobox.com
Note that this only goes for the git project. If you're e.g. using some
well-known vendors of LTS software they may themselves commit to
backporting patches to git and other software within their LTS window
(with mixed results).
I hope that helps!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Git v2.20.1 EOS date
2022-08-02 8:34 Git v2.20.1 EOS date Nicolas MAFFRE
2022-08-02 9:26 ` Ævar Arnfjörð Bjarmason
@ 2022-08-02 16:12 ` Junio C Hamano
1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2022-08-02 16:12 UTC (permalink / raw)
To: Nicolas MAFFRE; +Cc: git
Nicolas MAFFRE <nicolas.maffre.external@airbus.com> 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.
^ permalink raw reply [flat|nested] 3+ messages in thread