Re: [Tails-dev] Release versioning

On 06/03/2015 12:38 PM, intrigeri wrote:
> sajolida wrote (01 Jun 2015 11:31:18 GMT) :
>> anonym:
>> Couldn't we add an extra number only when we do an
>> emergency release?
>
> I think we can, and we should.

Let's just be clear on that it is the action of adding an extra *last*
number for emergency releases only that fixes the issue that intrigeri
originally raised.

>>> We could adopt a "even second number for bugfix releases, odd for
>>> major/feature releases" scheme (similar to what Linux used before),
>>> which would fit in perfectly with how we have been alternating between
>>> them so far (which I quite like and hope we will continue with). For
>>> emergency releases the third number would then serve the function you
>>> propose for the fourth number. If we ever want to release two major
>>> releases in a row, or want to postpone a major release, then we just
>>> increment by two.
>
>> ... or change from odd/even to even/odd. If we consider that this is
>> only meaningful internally and only happens on rare occasions.
>> Skipping a number might feel weird to users, but I think it's no big
>> deal either.
>
> I would personally really dislike having to deal with
> odd/even->even/odd changes of meaning. The ability to easily tell if
> a past or future release was or will be a major or a minor one is
> critical to me for planning work, deliverables, etc. Of course I'm
> totally biased on this one, but I feel it's much more important that
> some minor weirdness for user-visible version numbers: I bet 99% of
> the users don't care about version numbers, and don't understand their
> meaning anyway, while these numbers impact a lot our daily work.

Switching between not making a distinction between even and odd numbers
is the obvious solution so there was a reason that I picked that weird
scheme. That reason wasn't stated, but it is that I too feel it's
important to quickly be able to tell whether a release was/is/will be a
major, bugfix or emergency one.

>> I'm also tempted to propose changing the first number with major Debian
>> versions (we already almost did that for Tails Wheezy). The way we deal
>> with it right now is not really related to what the user experiences as
>> a "big change" as our improvements come in gradually. Still, a change in
>> Debian version is both a huge work for us and a big change for the user
>> (Tails Wheezy and Jessie both introduce a big change in the appearance
>> of the desktop environment, not to mention all the major updates of
>> included software).
>
> I like it.
>
> I'm tempted to amend this proposal with "first number matches Debian's
> major release version", e.g. Tails/Jessie would be Tails 8.0, but I'm
> not convinced myself that this would add much value => food for
> thought, if you folks find a convincing argument in favour of it,
> please state it, but before that happens, no need to explain why it
> wouldn't be good.

Quite a lot of user-facing changes are to be expected with Debian major
upgrades, so incrementing the first number kinda makes sense. For users
the 1.0.1 -> 1.1 upgrade was obviously more significant (mostly due to
the GNOME 2 -> 3 transition, and no IUK) than 0.23 -> 1.0, or perhaps
even any upgrade we ever released. When we release the first Tails based
on Jessie, the changes will be similarly big, and it may appear weird if
that happens with a tiny bump of the second number. I guess Debian geeks
also would appreciate to quickly be able to see what version of Debian
that Tails is based on. Of course, given how much we install from
testing/sid/backports, that will only be a half-truth.

Tails 1.0 was about some sort of feature-completeness according to plans
we had worked on for years. While there always will be more
Tails-specific improvements we can do, I wonder if we ever will need to
do something like that again. Well, perhaps if we do something that
fundamentally changes Tails, like Tails/Cubes or similar. Any way, the
point I'm trying to make is, if we do what you propose, then we lose the
control of the first number, and cannot use it for our own visions. Do
we care?

>> As you can see, I'm generally more tempted to have version numbers
>> relevant for the user than for us.
>
> This seems to be one point we disagree about in theory, but I'm sure
> we can find consensual solutions when looking at the practical aspects :)

I'm in the middle. I think the even/odd scheme already improves the
situation for our users (e.g. makes them more readable and easier to
distinguish) even with the *potential* version skipping, so I think it's
a good compromise.

Cheers!