"Neal Kreitzinger" <neal@xxxxxxxx> writes: > What is the best way for me (a git user) to determine what is currently > the oldest supported version of git (the oldest version still getting > bugfixes)? IOW, when can I tell that my version of git is no longer > supported? "A note from the maintainer" only promises that the latest major release (as of this writing, 1.7.9) gets regular maintenance releases until the next major release happens. When queuing a fix to an old bug, however, I try to build a topic branch for that fix from as old an release as practical, in order to make sure that older maintenance tracks could benefit, and I do give updates for older maintenance tracks when able (but no promises). For example, during the last cycle leading to 1.7.9, in other words, back when 1.7.8 was the latest major release, in addition to the maintenance releases 1.7.8.1, 1.7.8.2, 1.7.8.3 and 1.7.8.4, maintenance releases for older version of Git were tagged (1.7.6.5, 1.7.7.5, and 1.7.7.6). Note that 1.7.6 was originally released on June 26th, 2011. One cycle of major release development is expected to last between 8 to 10 weeks, so keeping two stale maintenance tracks in addition to the latest maintenance track alive would roughly translate to 6 months shelf life for an ancient release. As other people mentioned, if you are on a (probably paid) support plan from a(n enterprise) distro, asking them would be the best way, and if you are running Git supplied as part of a distro, the distro would dictate the version it supplies to you, so asking here would not help very much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html