[RFD] helping distributors by changing the release schedule?

Seeing that some distros seem to have botched their own backporting of gitk patches to maintenance tracks that are older than what we would support, I am wondering if we can do something to help them, without bending over backwards beyond reasonable effort that should be expected of us. The latest security fixes went to 8 maintenance tracks but I suspect it is probably 5 or 6 too many.

Here is an idea.

What would happen if we stop tagging any releases, and instead change the "release" model to tag the commit that happens to be at the tip of "master" once a month, strictly based on time (so after Git 2.50.0, we would have Git 2.50.202508 and then the next one would be Git 2.50.202509, if we decided to do this once every month)?

If we "release" reasonably often enough to make the distinction between the tags so smooth and meaningless, would it help in weaning the distros off of their mentality that pick one "major" version and stick to that version unless the user upgrades the Operating System version as a whole? After all, we do not make changes that are backward-incompatible at the end-user level, and the "we stick to a given single major released version to give stability to our users" mantra that leads distros to ship and support an ancient version is hurting them (and their users) more than helping.

On 2025-07-10 at 22:16:14, Junio C Hamano wrote:

I don't think this is going to help. We do, from time to time, make incompatible changes (e.g., changes to defaults), as well as user-visible changes which are not expected in a stable release (e.g., advice.defaultBranchName)[0]. There are also just bugs that crop up from time to time: I remember that one time I broke things when cloning two files that only differed in case if it was a case-insensitive file system. Users will not appreciate that kind of addition to their stable OS[1].

Most non-rolling-release distributions will not want new non-security updates, no matter how we package them. Distros already are not delighted by the fact that Chromium and non-ESR Firefox release new versions every six weeks, often with new toolchain requirements, and _every_ major release is a security update and therefore must be shipped no matter what.

If you want to do this to help users and provide them more frequent releases, great. If you want to do this to help distros, I fear that you're not going to get many adopters.

If it makes you feel any better, this is a common issue for upstreams and it certainly was a problem when I was one of the maintainers of Git LFS, since people would use versions from the distro that had a bug we'd fixed years before. I'm not sure there's a great solution out there.

[0] I very much wanted the underlying feature and was looking forward to it (and still think it's great, to be clear), but the thing that got me to set init.defaultBranch nearly immediately was the giant advice message that I didn't want to see every time I initialized a repository. This is the kind of change which users would be annoyed to see on a stable upgrade. [1] Many companies, mine included, use unattended-upgrades to automatically apply security updates on a periodic basis. Any sort of substantial change to the package risks breaking users doing this in a very noticeable production incident kind of way.