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'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.
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.
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)
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.
Cheers!
