Re: Why does Debian have code names for releases?
On Sat 01 Jul 2023 at 11:34:53 (-0400), Dan Ritter wrote:
> David Wright wrote:
> > On Mon 26 Jun 2023 at 17:22:04 (-0400), Jeffrey Walton wrote:
> > > On Mon, Jun 26, 2023 at 4:45 PM Dan Ritter <dsr@randomstring.org> wrote:
> > > > riveravaldez wrote:
> > > > > It would be possible, as an alternative, to populate sources.list with '2021',
> > > > > for instance, instead of 'bullseye', 'bookworm', etc.?
> > > > >
> > > > > We could have something like, 'Debian 2023 - Bookworm', so, preserving
> > > > > tradition, but allowing '2023' to be used as an alternative replacement of
> > > > > the traditional name maybe?
> > > > >
> > > > > Just an idea, looking for a simple solution...
> > > > >
> > > > > BTW, considering Debian doesn't have the marketing impositions of any
> > > > > proprietary commercial product, I find 'Debian 2021', 'Debian 2023', etc.,
> > > > > reasonably appealing...
> > > >
> > > > This would also be useful in my efforts to explain to my boss
> > > > why we're upgrading the machines.
> > > >
> > > > "It's 2023 and we're running Debian 2021. It's time to upgrade."
> > >
> > > ++
> >
> > I don't see how that works. What would your codename be, instead of
> > trixie? How do you know?
>
> I wouldn't care, because "2023" would be a synonym for
> "bookworm" in all the appropriate files.
Now that bookworm has been released, it's straightforward to assign
to it a Release Number of 2023. But the OP was querying the invention
of the codename trixie. I'm asking what alternative would you choose?
> > a project, and everyone knows what they're talking about. Unlike numbers,
> > names are memorable and unambiguous (when well-chosen).
>
> buster, bullseye, bookworm. So we can't depend on them to be
> well-chosen.
What's not well-chosen about any one of those codenames? (I know some
people have difficulty distinguishing between words with the same
initial letter, even though their common meanings are completely
different.)
BTW nobody is forcing people to carry on using codenames after they've
been given release numbers. It just says something about their usefulness.
> > You don't have to memorize all of Debian's codenames in order, do you?
> > There are about three or four in current use at any one time. (And the
> > release numbers might be monotonic, but they're not sequential, so
> > memorizing them would be just as tricky.)
>
> Since I've been using Debian since ... 1.3 ? I have been exposed
> to at least a dozen names.
>
> It would always have been of more benefit to be able to say
> "that went stable in 2002" or "next stable release will probably
> be in 2025" rather than "3 Woody" and "13 Trixie". Keeping the
> fun name is absolutely fine and indeed useful -- because
> schedules slip and no software should be released before its
> time.
>
> It's just that, when Trixie becomes stable, it would be very
> useful to be able to put "2025" or "2026" in all my
> documentation and config files instead of "13 Trixie".
I don't think it's sensible to use bare year numbers for releases,
let alone for codenames for as yet unreleased versions, even where
the dates were thought to be predictable. Take a couple of recent
posts, transcribing them from codenames into year numbers:
I'm not sure what you're reading into that. The 2021 manpage has a
copyright date of 2006 (Red Hat). But if we look at service itself,
which is a script, we can see that the ?earliest Debian version was
written in 2004 by our very own John Hasler, for 2005 through 2009,
by which time the version we have now, I think, joins it, and
replaces it in 2011.
It's not immediately clear that 2006 and 2004 are literal dates,
whereas the other numbers were originally codenames.
You say your system is pre-2017, ie 2015. That means that you will
have had both iproute2 and net-tools installed, as in 2015 they are
both ranked important. AFAICT iproute2 has never been ranked lower
than that, and its predecessor, iproute, was important as far back
as 2009. (Earlier than that, it could only be optional, because you
needed various options to have been compiled into the kernel.)
These numbers are all standing for codenames. However, the dates that
they now superficially resemble are misleading, because the ranking
decisions are likely to have been made up to two years or more earlier
than it would seem from the numbers.
Cheers,
David.
Reply to: