Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 25.06.19 um 08:08 schrieb Ansgar:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
>
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
>
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
TLDR; year based release identifiers should be prefered since they are
much more intuitive to reason about than codenames and sequentialy
numbered release identifiers.
If Debian should improve/change release identifiers, then I'd suggest to
ponder a year based versioning scheme (as Ubuntu is using).
As others here I am starting to get confused by the release code names,
as are my peers that are not that much into Debian. And sequential
release numbers are devoid of any semantics except for their
monotonically increasing character.
On the other hand, using year numbers as release identifiers has the
advantage of:
* getting rid of the need to remember arbitrary names and their sequence
* being linked to and rooted in everyday human experience, which makes
it intuitive and easy to reason about releases
When reasoning about an installation of Ubuntu "14.04" one can easily
come to the conclusion, that it's probably wise to upgrade, that release
being 5 years old, whereas an "16.04" might still smell reasonably fresh
and is probalby still OK to run.
Let's seriously consider using year based release identifiers.
*t
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: [...] > As others here I am starting to get confused by the release code > names, as are my peers that are not that much into Debian. And > sequential release numbers are devoid of any semantics except for > their monotonically increasing character. [...] And yet you *wouldn't* be confused when Debian 2019.7 is released in 2021? -- Jeremy Stanley signature.asc Description: PGP signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 29.06.19 um 14:41 schrieb Jeremy Stanley: > On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: > [...] >> As others here I am starting to get confused by the release code >> names, as are my peers that are not that much into Debian. And >> sequential release numbers are devoid of any semantics except for >> their monotonically increasing character. > [...] > > And yet you *wouldn't* be confused when Debian 2019.7 is released in > 2021? That's right, I don't think that'd confuse me. The reason it wouldn't confuse me, is that I expect releases to be updated eventually and that can happen at any time in the future - f.ex. in 2021. *t
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: > TLDR; year based release identifiers should be prefered since they are > much more intuitive to reason about than codenames and sequentialy > numbered release identifiers. > > If Debian should improve/change release identifiers, then I'd suggest to > ponder a year based versioning scheme (as Ubuntu is using). This only works with Ubuntu because they set the release date in advance. -- WBR, wRAR signature.asc Description: PGP signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: > On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: >> TLDR; year based release identifiers should be prefered since they are >> much more intuitive to reason about than codenames and sequentialy >> numbered release identifiers. >> >> If Debian should improve/change release identifiers, then I'd suggest to >> ponder a year based versioning scheme (as Ubuntu is using). > This only works with Ubuntu because they set the release date in advance. You assign the year to the release identifier when the release is ready: release_id = now().year(). There's certainly some infrastructure stuff that needs that release_id that needs to be prepared in advance, but I think that can be done pragmatically, when the release is "99%" ready. Am I missing something? *t
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 29/06/2019 17:27, Tomas Pospisek wrote: > Am 29.06.19 um 14:41 schrieb Jeremy Stanley: >> On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: >> [...] >>> As others here I am starting to get confused by the release code >>> names, as are my peers that are not that much into Debian. And >>> sequential release numbers are devoid of any semantics except for >>> their monotonically increasing character. >> [...] >> >> And yet you *wouldn't* be confused when Debian 2019.7 is released in >> 2021? > > That's right, I don't think that'd confuse me. The reason it wouldn't > confuse me, is that I expect releases to be updated eventually and that > can happen at any time in the future - f.ex. in 2021. > *t > It will confuse me because in 2021 I will expect release 2021 . Furthermore, will .7 stand for July ? Jerome signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 06:17:12PM +0400, Jerome BENOIT wrote: > >>> As others here I am starting to get confused by the release code > >>> names, as are my peers that are not that much into Debian. And > >>> sequential release numbers are devoid of any semantics except for > >>> their monotonically increasing character. > >> [...] > >> > >> And yet you *wouldn't* be confused when Debian 2019.7 is released in > >> 2021? > > > > That's right, I don't think that'd confuse me. The reason it wouldn't > > confuse me, is that I expect releases to be updated eventually and that > > can happen at any time in the future - f.ex. in 2021. > > *t > > > > It will confuse me because in 2021 I will expect release 2021 . > Furthermore, will .7 stand for July ? I assume it's about point releases (which, again, Ubuntu doesn't do AFAIK). -- WBR, wRAR signature.asc Description: PGP signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
在 2019-06-29六的 20:21 +0500，Andrey Rahmatullin写道：
> On Sat, Jun 29, 2019 at 06:17:12PM +0400, Jerome BENOIT wrote:
> > > > > As others here I am starting to get confused by the release code
> > > > > names, as are my peers that are not that much into Debian. And
> > > > > sequential release numbers are devoid of any semantics except for
> > > > > their monotonically increasing character.
> > > > [...]
> > > >
> > > > And yet you *wouldn't* be confused when Debian 2019.7 is released in
> > > > 2021?
> > >
> > > That's right, I don't think that'd confuse me. The reason it wouldn't
> > > confuse me, is that I expect releases to be updated eventually and that
> > > can happen at any time in the future - f.ex. in 2021.
> > > *t
> > >
> >
> > It will confuse me because in 2021 I will expect release 2021 .
> > Furthermore, will .7 stand for July ?
> I assume it's about point releases (which, again, Ubuntu doesn't do
> AFAIK).
I'm not sure about other issues but Ubuntu *do* make point releases for LTS.
There's something like Ubuntu 16.04.{,1,2,3,4}, etc. Their corresponding
(point) release dates are, of course, not in year 2016. As a result I think
it's not an issue.
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 6/29/19 3:33 PM, Tomas Pospisek wrote: > Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: >> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: >>> TLDR; year based release identifiers should be prefered since they are >>> much more intuitive to reason about than codenames and sequentialy >>> numbered release identifiers. >>> >>> If Debian should improve/change release identifiers, then I'd suggest to >>> ponder a year based versioning scheme (as Ubuntu is using). >> This only works with Ubuntu because they set the release date in advance. > > You assign the year to the release identifier when the release is ready: > release_id = now().year(). There's certainly some infrastructure stuff > that needs that release_id that needs to be prepared in advance, but I > think that can be done pragmatically, when the release is "99%" ready. > Am I missing something? > *t Thanks, but no. In some software we have in buster, they already have hard-wired the names of the 2 next Debian releases. How would you do this with years if we don't know the release dates in advance? Besides this, I very much dislike the way it sounds. :) Thomas
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 8:16 PM Tomas Pospisek wrote: > Let's seriously consider using year based release identifiers. At this point in the thread it is very clear that which identifier one prefers is very individual and dependent on use-cases. So we should add support for more individuals and use-cases in order to accommodate everyone's preferences. Killing off use-cases by switching between identifier styles isn't the right way to go. I suggest that we add an "Aliases" field to the Release file. Then apt could use that to silence its warnings about sources.list not matching Suite/Codename. Then we could request ftp-master update dak to populate the Aliases field and add symlinks for all aliases. Any volunteers to write the needed patches? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
It will confuse me because in 2021 I will expect release 2021 . Furthermore, will .7 stand for July ? I assume it's about point releases (which, again, Ubuntu doesn't do AFAIK). The keyword will be education - i wrote some times ago: Let people use wht they are happy with - it will take a blog entry or two to let users know what 20xy.z means - i can't resist and bring it to the point: If there will be a release 2020.0 and 2020.1 - and there will be release notes - do we really assume our users are to dumb to get it??? Cheers Alf
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Another issue is that with a sequential scheme I always know what the next version is whereas if a year based scheme is used without a set schedule the version after 19 may be anything from 19 to 25. Sincerely, Moshe Piekarski -- There's no such thing as a stupid question, But there are plenty of inquisitive idiots. signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Hello, On 30/06/2019 06:53, Alf Gaida wrote: >>> It will confuse me because in 2021 I will expect release 2021 . >>> Furthermore, will .7 stand for July ? >> I assume it's about point releases (which, again, Ubuntu doesn't do >> AFAIK). >> > The keyword will be education - i wrote some times ago: Let people use wht > they are happy with - it will take a blog entry or two to let users know what > 20xy.z means - i can't resist and bring it to the point: > > If there will be a release 2020.0 and 2020.1 - and there will be release > notes - do we really assume our users are to dumb to get it??? I assume that users can understand the current codename scheme used in Debian. And I found it funny when I read for the first time the explanation on the website (there was no blog at this glorious time). If order is a question (which version comes before the other one), we can impose that the first letter of the codenames must fellow the alphabetic order. Jerome > > Cheers Alf > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Hi, Am 29.06.19 um 23:32 schrieb Thomas Goirand: > On 6/29/19 3:33 PM, Tomas Pospisek wrote: >> Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: >>> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: TLDR; year based release identifiers should be prefered since they are much more intuitive to reason about than codenames and sequentialy numbered release identifiers. If Debian should improve/change release identifiers, then I'd suggest to ponder a year based versioning scheme (as Ubuntu is using). >>> This only works with Ubuntu because they set the release date in advance. >> >> You assign the year to the release identifier when the release is ready: >> release_id = now().year(). There's certainly some infrastructure stuff >> that needs that release_id that needs to be prepared in advance, but I >> think that can be done pragmatically, when the release is "99%" ready. >> Am I missing something? >> *t [...] > > In some software we have in buster, they already have hard-wired the > names of the 2 next Debian releases. How would you do this with years if > we don't know the release dates in advance? Allow me to start with the inverse question: should the fact that software makes assumptions about the future preclude humans from shaping that future as they deem best? Now what if there was a way to have both: a better naming scheme *and* compatibility with software that hard codes the future? Lets see - one possibility would be to have both year based release identifiers and code name based ones. That could possibly solve both issues (better naming + compatibility). Or maybe there are yet other ways to solve the supposed contradiction? F.ex. updating the hard-coded SW comes to my mind. > Besides this, I very much dislike the way it sounds. :) The way what sounds? *t
