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
Reply to: