Re: Why does Debian have code names for releases?
On Sun 02 Jul 2023 at 11:30:39 (-0400), Dan Ritter wrote:
> 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.
Suit yourself; the release names are not of any particular interest
to me per se. They might be important for marketing and advocacy,
but I'm not involved in that. All power to those who are: they
probably hold views on the best names to 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.)
>
> 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 know anything about your organisation. The environment
I worked in was not principally concerned with computing, and
I don't think my boss had any knowledge beyond the word "Linux",
(possibly). My users were immersed in my software, but didn't
concern themselves particularly with what OS was running it.
As a user myself (of the university computing service), we were
surveyed about application software that could/would/ought to
be made available, but not the timing of OS upgrades, which
required coordination across departments. When I served for a
while on the appropriate committee, I remember our views being
sought on which manufacturers would be asked to submit bids
for the replacement system. We didn't discuss OS versions from
five years ago, using either codenames or Sunday best names.
> > 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.
That would seem more reasonable.
> > 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.
One disadvantage of using years I haven't seen considered is that
casual potential users may have an aversion to buying, in 2024,
something that's labelled 2023. I googled for an appropriate term:
upgraditis perhaps.
On the way, google gave a list with these two consecutive hits:
Why the latest software update isn't always the best
Digital Trends
https://www.digitaltrends.com › Computing › Products
Dec 19, 2015 — The update debate: Why the latest version
of software isn't always the best. Jon Martindale.
Why You Should Always Use the Latest Version of ...
WPBeginner
https://www.wpbeginner.com › Beginners Guide
Dec 3, 2020 — Want to know the pros and cons of updating
WordPress? In this article, we will explain why it is
crucial that you always use the latest version ...
Cheers,
David.
Reply to: