Re: Debian testing - release number
On Thu 05 Jul 2018 at 11:53:45 (+0100), Joe wrote:
> On Thu, 5 Jul 2018 10:09:36 +0000 (UTC)
> Curt <curty@free.fr> wrote:
>
>
> >
> > The problem I'm looking at is that the Debian testing/unstable
> > releases do not have a version number and are not going to be
> > receiving one any time soon (the tradition of not according a number
> > to these two releases being of the utmost venerability).
>
> How can they? They are never released, and unstable receives new
> software, sometimes new software *versions*, minute by minute. I don't
> know how much new code unstable gets per day, but my workstation
> installation typically downloads something of the order of 50MB,
> usually dozens of packages. Testing is a bit more stable, but
> outside the freeze, basically follows unstable with about ten days'
> delay for a given package. In that context, what can 'release number'
> mean? It can only make sense for stable.
Of course; that's the argument made by the release managers, and it's
the rule that was broken when "1.0" was released in error, which is
why it was skipped, buzz becoming 1.1. What the release managers
rightly resist is wishlist reports for changing the released values
given by debian_version and its relatives like os-release and
lsb_release. I expect distributors follow this policy.
But if you're a sysadmin who has a script that wants/needs a version
*number* for any reason, then /etc/debian_version is the safest file
to modify. It guarantees that released Debian software won't change
its behaviour (doing so would be a bug), but unreleased and
third-party software would behave as the sysadmin desires.
But playing devil's advocate, there's no reason why Debian couldn't
have made a different choice. The obvious one, which I've seen
elsewhere, is to reserve the value N.0 for testing (10.0 in the
case of buster). The new release would be N.1 with point releases
as before.
Myself, I prefer dealing with codenames anyway, so I have no axe
to grind. I don't modify debian_version, but use the first line
of sources.list for my own purposes, mainly the selection of
configuration files by symlinks.
Cheers,
David.
Reply to: