{"thread":{"id":"63779","subject":"[RFD] helping distributors by changing the release schedule?","startedAt":"2025-07-10T22:16:17Z","lastAt":"2025-07-10T22:36:22Z","messageCount":2,"participants":["Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"521783","messageId":"xmqqldov4rpt.fsf@gitster.g","threadId":"63779","inReplyTo":null,"subject":"[RFD] helping distributors by changing the release schedule?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-10T22:16:14Z","receivedAt":"2025-07-10T22:16:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seeing that some distros seem to have botched their own backporting\nof gitk patches to maintenance tracks that are older than what we\nwould support, I am wondering if we can do something to help them,\nwithout bending over backwards beyond reasonable effort that should\nbe expected of us.  The latest security fixes went to 8 maintenance\ntracks but I suspect it is probably 5 or 6 too many.\n\nHere is an idea.\n\nWhat would happen if we stop tagging any releases, and instead\nchange the \"release\" model to tag the commit that happens to be at\nthe tip of \"master\" once a month, strictly based on time (so after\nGit 2.50.0, we would have Git 2.50.202508 and then the next one\nwould be Git 2.50.202509, if we decided to do this once every\nmonth)?\n\nIf we \"release\" reasonably often enough to make the distinction\nbetween the tags so smooth and meaningless, would it help in weaning\nthe distros off of their mentality that pick one \"major\" version and\nstick to that version unless the user upgrades the Operating System\nversion as a whole?  After all, we do not make changes that are\nbackward-incompatible at the end-user level, and the \"we stick to a\ngiven single major released version to give stability to our users\"\nmantra that leads distros to ship and support an ancient version is\nhurting them (and their users) more than helping.\n\n"},{"id":"521787","messageId":"aHBAZLC4xTcy9-UR@fruit.crustytoothpaste.net","threadId":"63779","inReplyTo":"xmqqldov4rpt.fsf@gitster.g","subject":"Re: [RFD] helping distributors by changing the release schedule?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-07-10T22:36:20Z","receivedAt":"2025-07-10T22:36:22Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-07-10 at 22:16:14, Junio C Hamano wrote:\n> If we \"release\" reasonably often enough to make the distinction\n> between the tags so smooth and meaningless, would it help in weaning\n> the distros off of their mentality that pick one \"major\" version and\n> stick to that version unless the user upgrades the Operating System\n> version as a whole?  After all, we do not make changes that are\n> backward-incompatible at the end-user level, and the \"we stick to a\n> given single major released version to give stability to our users\"\n> mantra that leads distros to ship and support an ancient version is\n> hurting them (and their users) more than helping.\n\nI don't think this is going to help.  We do, from time to time, make\nincompatible changes (e.g., changes to defaults), as well as\nuser-visible changes which are not expected in a stable release (e.g.,\nadvice.defaultBranchName)[0].  There are also just bugs that crop up\nfrom time to time: I remember that one time I broke things when cloning\ntwo files that only differed in case if it was a case-insensitive file\nsystem.  Users will not appreciate that kind of addition to their stable\nOS[1].\n\nMost non-rolling-release distributions will not want new non-security\nupdates, no matter how we package them.  Distros already are not\ndelighted by the fact that Chromium and non-ESR Firefox release new\nversions every six weeks, often with new toolchain requirements, and\n_every_ major release is a security update and therefore must be shipped\nno matter what.\n\nIf you want to do this to help users and provide them more frequent\nreleases, great.  If you want to do this to help distros, I fear that\nyou're not going to get many adopters.\n\nIf it makes you feel any better, this is a common issue for upstreams\nand it certainly was a problem when I was one of the maintainers of Git\nLFS, since people would use versions from the distro that had a bug we'd\nfixed years before.  I'm not sure there's a great solution out there.\n\n[0] I very much wanted the underlying feature and was looking forward to\nit (and still think it's great, to be clear), but the thing that got me\nto set init.defaultBranch nearly immediately was the giant advice\nmessage that I didn't want to see every time I initialized a repository.\nThis is the kind of change which users would be annoyed to see on a\nstable upgrade.\n[1] Many companies, mine included, use unattended-upgrades to\nautomatically apply security updates on a periodic basis.  Any sort of\nsubstantial change to the package risks breaking users doing this in a\nvery noticeable production incident kind of way.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}