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:
signature.asc
Description: PGP signature
