Re: Why does Debian have code names for releases?
David Wright wrote:
> 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?
Trixie is what we would use up until code freeze, at which point
we would have the option of continuing to call it trixie, but it
would gain the synonym 2023.
> > > 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.)
When I talk to my users and my boss, all of them have trouble
remembering them and keeping the order straight.
And when I talk about releases older than oldoldstable, I have
trouble too.
> 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.
I am amenable to "stable2023" or "debian2023" or any reasonable,
unambiguous encoding standardization along those lines.
> 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.
They went into effect when each stable version was released. Decisions
are obviously made before they are implemented, and as I said, I'm not
calling for a replacement, I'm calling for a substitutable predictable
and postdictable alias implemented when the year of the stable release
becomes extremely likely.
The marginal case where unpredictable delays push a stable
release out to December, and then possibly into the next
calendar year, is not very concerning to me as long as there is
no more than one stable .0 release per calendar year.
-dsr-
Reply to: