Debian and code names

Debian typically uses code names to refer to its releases, starting with the Toy Story character names used (mostly) instead of numbers. The "Buster" release is due on July 6 and you will rarely hear it referred to as "Debian 10". There are some other code names used for repository (or suite) names in the Debian infrastructure; "stable", "testing", "unstable", "oldstable", and sometimes even "oldoldstable" are all used as part of the sources for the APT packaging tool. But code names of any sort are hard to keep track of; a discussion on the debian-devel mailing list looks at moving away from, at least, some of the repository code names.

The issue was raised by Ansgar Burchardt, who wondered if it made sense to move away from the stable, unstable, and testing suite names in the sources.list file used by APT. Those labels, except for unstable, change the release they are pointing at when a new release gets made. Currently stable points to "Jessie Stretch" (Debian 9), while testing points to Buster. Soon, stable will point to Buster, testing will point at "Bullseye", which will become Debian 11.

He asked about using the release code names directly, instead, so that pointing a system at Stretch would continue to get packages from that release. But he also thought it would be nice to completely route around the code names, which "confuse people". He suggested lines that looked like the following in sources.list:

    deb http://deb.debian.org/debian debian11 main
    deb http://security.debian.org/debian-security debian11-security main

Andrei Popescu pointed out some of the perils of using stable and testing around the time of a release. Many users have (mostly incorrectly) trained themselves to do a apt-get dist-upgrade instead of a regular apt-get upgrade to pick up new package versions, but that can go badly awry if stable has just changed. Those who stick with testing, he said, are really looking for a rolling release, so perhaps testing should be renamed to "rolling"—"or 'roling' to emphasize that it's incomplete :p".

The code names are particularly hard for those only tangentially connected to Debian, Simon McVittie said. He notes that there will be three releases with code names that start with "B" before too long; after Buster and Bullseye comes Bookworm. Originally, part of the reason for code names was because it was not clear whether the next release would be considered a point release or not: "we didn't know whether etch would be released as Debian 3.2 or Debian 4.0". Now each release is a major version bump, so it would help outsiders to use those more:

But Adam Borowski is adamant that the code names are easier to work with. He complained that he had to look up whether Debian 11 was Buster or Bullseye, but others have the opposite problem. Going back in time is difficult as well, as Wouter Verhelst related:

Philip Hands also has trouble remembering code names, but he (and others) suggested: "Can we not just have both?" Certainly the testing suite name is considered useful by many, so it will presumably remain in any plan that might emerge. And Ian Jackson thinks that the other suite names should stick around for reference purposes but that using "debian11" in sources.list should be the default going forward:

Michael Stone summed up the thinking of many in the thread with regard to names, rather than versions, in sources.list:

Several lamented that it was painful to actually do that lookup at times. Wikipedia has a good reference page, but something closer to home would be useful. McVittie pointed to the distro-info-data package, which has those mappings in a CSV file and provides bindings for various languages; it is used by the lsb-release package to report distribution version information. That helps, but the consensus still seems to be that providing a version-number-based system (in addition to the existing suite names) makes sense.

In fact, Jackson suggested a call for rough consensus as was done by Debian project leader Sam Hartman for the dh discussion in June. Hartman seconded that call, suggesting that Burchardt do so "as the developer who started the discussion". So far, that has not occurred, however.

Perhaps inevitably, the idea of moving to year-based version numbers (or "release identifiers") was raised; Tomas Pospisek said that the code names are getting confusing and that "sequential release numbers are devoid of any semantics except for their monotonically increasing character". Year-based version numbers is, of course, what Ubuntu uses, but there is a big difference between the two: Ubuntu sets its release date in advance, while Debian release dates are rather more fluid. The pros and cons of that approach were discussed, with the idea of alphabetically increasing code names thrown in for good measure, but few beyond Pospisek seemed wildly enthused by the idea. As Paul Wise put it:

That's where things stand at this point. In general, code names are most useful within a community, rather than as a marketing or other tool to communicate with outsiders. Even when those names follow a clear pattern (e.g. Ubuntu, Android) they still seem to confuse to some extent. Numbers have the advantage of predictability, though without some kind of real-world mapping (e.g. date-based) the advantage is somewhat limited. But defaulting to a world where sources.list does not point to "stable", which suddenly changes at release time, seems like a goal worth pursuing. Outsiders and insiders alike can perhaps agree on that part.