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