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