On Tue, 25 Jun 2019 at 13:11:09 +0500, Andrey Rahmatullin wrote:
> On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote:
> > Can you please elaborate on the "confuse people"?
>
> I guess only (most?) Debian contributors and hardcore Debian users
> remember the order of the codenames and their mappings to current
> stable/oldstable/testing and to numeric versions.
Yes, exactly. This is a frequent request from those of my colleagues
who mostly use other distributions, but occasionally have to interact
with Debian, and can't remember whether stretch is older or newer than
jessie. This is going to be particularly bad after the buster release,
when buster and bullseye are current, and even worse after the bullseye
release, when buster, bullseye and bookworm will all be relevant.
Ubuntu is easier in some ways (because the alphabetical codenames go in
a logical sequence) but harder in others (because the distinction between
LTS and non-LTS isn't obvious from the codenames).
Back when the release team decided on a per-release basis whether this
was a "major" or "minor" release, we had the excuse that we had to use
a codename for testing because we didn't know whether etch would be
released as Debian 3.2 or Debian 4.0; but now that we've decided that
every release is a major version, we can predict well in advance that
Debian 10 will be followed by Debian 11 and Debian 12, so there doesn't
seem a whole lot of point in obfuscating it.
With more emphasis on the version numbers, my non-Debian colleagues would
still have to learn (or look up) which release is the current stable,
but given that information they would immediately also know which release
was the previous one (subtract 1) and which release is under development
(add 1).
Referring to testing in speech/writing as something like Debian 10
alphas/betas/pre-releases (to express that it *will be* Debian 10, but
it isn't really Debian 10 *yet*) might make more sense to non-Debian
people, and might have the desirable side-effect of having more Debian
contributors get the message that it's a means to an end (making
the next release happen) rather than a product in its own right. In
machine-readable contexts like sources.list it's probably best to use
something like debian10 (or deb10, as in stable updates' version strings,
or just 10) so that it doesn't have to change on release day.
smcv
