On September 7, 2025 12:10 AM, Elijah Newren wrote: >Sorry for the delay; life outside of work is challenging at the moment... > I am going to address the critical point mentioned below and snip the rest for brevity. >I still don't see why distributors _must_ ship the latest version of Git and why folks >on some platforms are considered broken if they are using a slightly older version. >Let me ask again: has anyone answered why this is considered mandatory? If they >have, I've missed it, but I've asked multiple times. Even if you want to lump >"distributors cannot build a newer version" under the umbrella of "breaking >changes", I argue it's a much different kind of break and one which merits different >timelines for handling than e.g. lumping it in with 3.0. I do not see that distributors _must_ ship the latest version. Suppose we are on 2.51.0 and a CVE comes out that prohibits its use in an organization that does not allow any medium-high to high CVEs. This represents hundreds of thousands of impacted users in my community alone. How does the CVE get applied if the latest cannot be built and the git team does not apply the CVE fixes to old versions. Personally, I do not care if git versions are different between work and home, or even between CI/CD and other platforms. I don't even care if I have to use JGit instead of git in some situations (which I see is a likely outcome of this discussion). Is there an official statement of what an LTS means? In other projects LTS is typically, and formally by policy 5 years. >From what others have said here, positions of 6 months, 3 years, and "apply it yourself if you want to continue to use git" have been made. The core problem of adding a breaking dependency is when a CVE comes out that prohibits git from being used at all. If the git team is not going to provide a clear statement, one way or another, if how CVEs (at whatever severity level) will not have a commitment of any kind, then distributors are essentially cast adrift and on our own. It would be helpful of those of us who donate our time, for no compensation, are able to plan for this in a meaningful way. Please remember that we have to justify our participation to our management teams to be allowed to continue to participate. Nothing is free from this end and if fixing (not just applying fixes) CVEs are now 100% our responsibility, if would be critical to know that when we build our business cases to our bosses, who I am fairly certain will say an emphatic no. Also remember that without support from the git team, the code base is no longer the same, meaning the auditors will not necessarily accept fixes from third-party sources. This particular point enabled adoption on some platforms, particularly NonStop. Adoption was at 1-2 customers when we had a divergent code based because some platform fixes being different from the standard code-base and could not be certified as valid. Once the code-base because common, adoption was rapid and enthusiastic. If this goes away, I suspect that adoption rates will go negative. I am aware that that particular discussion is actually happening in some organizations in my community right now, with companies looking for alternatives to git based on this discussion thread. With over a decade of respect and participation, Randall
