[RFD] helping distributors by changing the release schedule?

[RFD] helping distributors by changing the release schedule?

[Junio C Hamano]

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.

Re: [RFD] helping distributors by changing the release schedule?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

On 2025-07-10 at 22:16:14, Junio C Hamano wrote:
> 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.

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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]