On 13/01/18 10:03, David Wright wrote: > On Fri 12 Jan 2018 at 14:01:34 (+0000), Ian Campbell wrote: >> On Fri, 2018-01-12 at 13:54 +0000, Holger Levsen wrote: >>> On Fri, Jan 12, 2018 at 08:49:05AM -0500, rhkra...@gmail.com wrote: >>>> But the various names and use of those names gets very frustrating >>>> for me, and >>>> I suspect I am not the only one. The numbered versions, the Toy >>>> Story names, >>>> and then the testing, stable, old stable, old old stable is just >>>> frustrating. >>> >>> >>> https://en.wikipedia.org/wiki/Debian_version_history explains this >>> nicely and is linked from https://en.wikipedia.org/wiki/Debian >> >> I took their point to be that if one needs a wiki page to follow the >> versioning scheme then perhaps the versioning scheme has an issue. > > I disagree with that, and with the view that you don't need 3½ > schemes to describe the situation. That page is a useful summary > for people unfamiliar with the schemes and their relationships.
I agree with rhkramer, that if you need to look it up, it's a bit confusing. I tend to think of releases by their codenames, and have to occasionally look up the numbers, and generally have no idea what's in 'LTS' status. > I would prefer, however, that buster were not described as 10, > nor bullseye 11, just as buzz was not released as version 1.0. You mean they shouldn't be numbered till they're released? And according to the wikipedia page, buzz never was 1.0; it was 1.1, released or otherwise. >> IIRC teams like the Press Team have a policy of always leading with the >> numerical version rather than the code names, presumably for this very >> reason, > > Which reason? The formal name of a release is the Release number. > As point releases are issued, the Release number changes; the > code name doesn't. When a release becomes ancient history, its > code name still applies to it and the all its point releases, > whatever numbering scheme is then in force. Except you can't really tell from the release number whether it's a new release or not. Historically, sometimes a point release has been a new release, and other times it hasn't. AFAIK a new code name is always 1:1 with needing to read the release notes and using dist-upgrade or whatever. >> but that doesn't carry over into "casual" conversation like the >> parent thread or the repo urls etc. > > No, for several reasons which may differ between people. In this > specific case, wheezy-backports packages are packaged for > installation on wheezy systems, but they're not part of any > Debian [0-9]+ release; using a Release number (which one?) would > carry misleading implications. > > Another reason: it's a convention that organisations use > because it works. It's less ambiguous to write jessie than 8 > especially in contexts where lots of numbers are being discussed, > and it's more memorable to most people. People use names, > computers like numbers. I don't think the 'number' as used here is particularly more computer-friendly; it's still a string. And sources.list uses names, and AFAIK doesn't translate to numbers before talking to the repo. > As for stable etc, at the users' end, they're designed to give > a seamless path for any particular system to evolve through the > upgrade process. Do they though? Is it ever recommended to let a 'stable' installation be upgraded to the next release without manual intervention and lots of care? I certainly always use codenames in sources.list, so I can control when the upgrade happens. > At the developers' end, they provide static > handles for the discussion of how packages migrate through the > repositories. LTS is somewhat similar. I guess LTS is more or less a synonym for 'oldoldstable', right? A moving target, anyway. > Some people always seem to remain confused. Perhaps they have > the same confusion with timezones, for similar reasons. Verging on personal, but whatever. Richard
signature.asc
Description: OpenPGP digital signature
