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 <d...@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-
