Re: [Tails-dev] Release versioning

Hi,

sajolida wrote (01 Jun 2015 11:31:18 GMT) :
> anonym:
> I feel more aligned with anonym's position.

Works for me too :)

> Do we need to have a constant number of positions in the version
> number scheme for technical reasons?

I don't think so.

> Couldn't we add an extra number only when we do an
> emergency release?

I think we can, and we should.

>> 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.

>> Here's a "benchmark" between our current scheme, the one you propose
>> (x.x.x.x) and the even/odd one I'm toying with, for our actual release
>> history since 1.0: [...]

> I like it.

+1

> 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.

> Regarding what we have been doing on our roadmap for 2.0 and 3.0 (give
> them broad objectives) we could maybe do the same again: give us broad
> directions for our work within a Debian lifetime.

I don't really understand what this idea/proposal means in practice.

> 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 :)

Cheers,
--
intrigeri