Re: Frustration over Debian naming
On Sat 13 Jan 2018 at 16:49:34 (+1300), Richard Hector wrote:
> 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, rhkramer@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.
That's right. My own experience with Debian only goes back to buzz
after it was released. (Before that I briefly used Slackware installed
onto FAT filesystems.)
But think back to late'95/early'96. You're about to build the first
full release, your version 1.0. It needs a name, if only to put on
the front of the filing cabinet/at the top of the directory tree.
Ambitiously, you write "1.0". Roll on mid'96 and someone erroneously
releases and distributes it.
Now you have two versions 1.0s, the legitimate one and the rogue one.
So now you've got to change the name of your project. All the files/
documents/correspondence about the project (which is unchanged at
this moment) has the wrong name on it.
Almost every business in the world has learnt the practice of using
static, neutral names for projects. A similar argument applies to
computers. Accounting probably give them inventory numbers, but
they need names, so up pops an RFC to give advice on dos and don'ts.
> >> 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.
That's true, but at least they collate (with care).
> And sources.list uses names, and
> AFAIK doesn't translate to numbers before talking to the repo.
That's right. The repository is built with code names. However it
is numbered upon release, stretch is forever stretch.
> > 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.
So do I. But plenty don't, as evidenced by postings here.
> > 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.
It's whatever the LTS team decide they have the resources to support
at any time and is generally composed of subsets of code names
(rather than versions).
I believe the number of code names has just been reduced, excluding
foo-backports which they had tried to cover.
> > Some people always seem to remain confused. Perhaps they have
> > the same confusion with timezones, for similar reasons.
>
> Verging on personal, but whatever.
Which person? It wasn't intended to be. It didn't touch upon
any specific confusion yet mentioned in this thread.
There's a group (for want of a better word) of people who have
thought that the versions are called stable etc, and the code
names are just nicknames that change as releases are published.
This can lead to confusion similar to timezones. Timezones
increase eastward, but noon migrates westward, and people get
called on the phone in the middle of the night.
Cheers,
David.
Reply to: