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
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"]
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"]
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"]
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"]
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"]
在 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 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"]
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"]
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 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 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 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
