On Thu, Aug 01, 2024 at 12:06:21PM -0700, Russ Allbery wrote: > The second thing that I'm not fond of is giving testing the version number > 13 when we plan on using 13 as the version number for the trixie release. > I fear that if we do that, someone (probably a third-party package > provider) will add some workaround or behavior change for a package based > on that version number for a problem that only ever existed in testing and > that was not in the actual 13 release. I would instead expect testing to > use some version number that is between stable and the version number that > will be assigned to the next release, to reflect that it is likely to > change substantially before Debian makes an actual release 13.
And we cannot even use 13~, since we might release trixie as 12.9 or something. So that decision would have to be taken early by the release team, and it is almost impossible to revert. Does the proposal include lanugage about what to put in the Version: field in debian/control of the proposed package? Would it be pulled in by a versioned dependency (in base-files)? > (If I were designing this from scratch, I'd give serious thought to using > even version numbers for releases and odd version numbers for testing, > similar to how Perl releases are versioned for very similar reasons. But > that's probably too big of a change for the level of benefit.) Using yy.mm as release version number is one of the things that Ubuntu does right. I'd suggest going that path should we decide to touch version numbering. > Presumably the RELEASE_TYPE setting of pre-release is supposed to help > with that, but (a) that variable doesn't seem to be documented in > os-release(5); (b) the sorts of packagers that I'm worried about are quite > likely to not make subtle distinctions like that, so the version is still > there as a potential foot-gun for people who aren't paying close > attention; and (c) I would argue that calling testing a "pre-release" is > not very accurate, since that applies that the contents are very similar > to the eventual release and are in a relatively late stage of testing. Local variables in os_release are unlikely to be picked up by distribution independent tools like ansible and are thus of very limited usefulness. > There's a lot of merit to Santiago's decision to not give unstable a > version number that I think still applies to testing even when it's > considered separately. It would be very nice to not have to do a two-stage distribution comparision in ansible playbooks or such, and to be able to do a numeric comparision. Personally, I currently reference my debian versions on codenames, which puts a lot of distribution specific knowledge about codenames into my playbooks. I am not very fond of that, but it is just a single stage, and it allows me to install new machines on trixie NOW and have them automatically migrate over when trixie becomes stable. I think that I had to define a local variable to accomplish this in my playbooks, but that's a few years in the past. It may be possible easier today. > > There was also a slight variant by Gioele, that again I fail to find now > > and it might be because of the bugs being rearranged, where > > testing-proposed-updates is used to upload testing-specific content. > > That seems like a better approach than the one proposed in the message > above, although I think it requires some manual intervention by the > release team. This doesn't seem like a serious problem given that uploads > are presumably quite infrequent and the package is trivial. For this method to work the package MUST be trivial, if not impossible to get wrong. Greetings Marc
