Simon McVittie <s...@debian.org> writes: > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote: >> Luca Boccassi <bl...@debian.org> writes:
>>> It is correct as-is. VERSION_ID is meant to identify a release, not >>> updates or point releases. A release as in, Debian Bookworm, or Fedora >>> 40, or Ubuntu Noble, and so on. >> Why would you not want to identify point releases? This really >> surprises me. > I think the idea is that two releases have a different VERSION_ID if and > only if they can both be fully up to date, but still remain > different. If we make the analogy of git, VERSION_ID labels a branch, > not a tag. Oh, thank you, this was not at all obvious to me. If this is indeed the case, that would be a useful clarification to add to the specification. This also explains the desire to identify testing as trixie, but not identify unstable as trixie. If one configures a testing system to point to trixie, then fully updating it will move it into the stable release when the stable release comes out. However, if one points a system at unstable, that system will never become a trixie system and will always continue to point to a different release. This is not an entirely clean analogy, since it's also possible to point a system at the testing suite directly, rather than using the code name, in which case that system will also never become trixie. So in that sense testing is simultaneously both trixie and not trixie depending on exactly how you configure apt. This sort of ambiguity is, I think, part of why this proposal generates so much discussion. Debian simply doesn't currently have clean semantics for testing. It exists in a sort of quantum superposition where it is multiple things simultaneously for different people, and this proposal is trying to label it in a way that collapses that state to match the mental model of one group of people, invalidating the mental model of a different group of people. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
