anonym:
> On 05/29/2015 05:19 PM, intrigeri wrote:
>> Hi,
>>
>> it popped up to my mind that our current versioning scheme is a bit
>> painful whenever we need to insert an unexpected release: e.g.
>> when we've put out 1.3.1, it "stole" a version number that was
>> "reserved", which can result in some confusion, e.g. when looking up
>> planning information in past email.
>
> Yes, this was quite annoying (i.e. it invalidated the original 1.3.1
> release schedule posted to this list).
>
>> Perhaps we should call all our expected releases a.b.c, and "bonus"
>> intermediary releases a.b.c.d? In the case at hand, instead of 1.3,
>> 1.3.1 and 1.3.2, this would have given 1.3.0, 1.3.0.1, and 1.3.1.
>
> I've been thinking about proposing *exactly* this but I've been unsure
> since introducing yet another number make them harder to read Let's face
> it, Firefox' and Chrome's version inflation is actually an instance of
> KISS. Personally I don't think we have to go that far, and do like to
> have a first number signifying significant milestones.
I feel more aligned with anonym's position. Do we need to have a
constant number of positions in the version number scheme for technical
reasons? Couldn't we add an extra number only when we do an emergency
release?
> I'm wondering how much the knowledge of whether a new Tails release is a
> major release or not really matters for users. After all, they should
> upgrade no matter what and should always read the release notes since
> there could significant changes even in bugfix releases (for security
> reasons). Hence it seems like making that distinction is only important
> for contributors, who we can expect more from for reading extra meaning
> in the version numbers.
I was going to propose this as well. Still note that whenever we issue a
major release, it gets more media attention, people talk about the new
features, etc.. But maybe that's because we advertise them better as
well and the press would do the same if we had a odd/even schema.
> 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.
> 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:
>
> Current x.x.x.x even/odd Release type
> 1.0 1.0 1.0 (bugfix)
> 1.0.1 1.0.1 1.2 (bugfix, a major release was skipped)
> 1.1 1.1 1.3 (major)
> 1.1.1 1.1.1 1.4 (bugfix)
> 1.1.2 1.1.1.1 1.4.1 (emergency)
> 1.2 1.2 1.5 (major)
> 1.2.1 1.2.1 1.6 (bugfix)
> 1.2.2 1.2.1.1 1.6.1 (emergency)
> 1.2.3 1.2.2 1.8 (bugfix, a major release was skipped)
> 1.3 1.3 1.9 (major)
> 1.3.1 1.3.0.1 1.9.1 (emergency)
> 1.3.2 1.3.1 1.10 (bugfix)
> 1.4 1.4 1.11 (major)
I like it.
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).
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.
As you can see, I'm generally more tempted to have version numbers
relevant for the user than for us.
> IMHO the times around 1.1..1.2.1 in our current scheme and 1.1..1.2.1.1
> in x.x.x.x looks pretty crazy (and we will have the same situation
> around 2.1), whereas the even/odd scheme always looks sane in terms of
> the amount of numbers. The only strange thing in that one are the jumps
> from two skipped major releases (1.1 and 1.7). I think a short
> explanation in the release notes would make it pretty clear that users
> didn't miss a Tails upgrade if we ever have to do that again.
>
> Perhaps I'm just beating at a problem that doesn't really exist and
> should stop now. :) No matter what, we definitely need a *separate*
> number for emergency releases. Also, I think we should do a better job
> at communicating what type (major/bugfix) each release is in the
> important places where contributors read about or plans, like in the
> release schedule sent to tails-dev@, our website's schedule, and in Redmine.
--
sajolida
