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! _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.