intrigeri: > sajolida: >> intrigeri: >>> - 2020-01-07: Release 4.2 (bugfix release, with one exception) >>> >>> Tails Upgrader MUST support Endless automatic upgrades (#15281); if >>> it's not ready in time, instead ship that in a beta by the end of >>> January; and then some minor adjustments are needed below. >>> >>> Automatic upgrade from 4.0 and 4.1, using the old upgrade system. > >> Are you confident that no RC is needed for this change? > > I need to give lots of background information so that I can > meaningfully answer this question. > > The problem with the Upgrader is that shipping changes in Tails N~rc1 > is useless in terms of QA: we will notice issues only when the few > users who installed this RC upgrade to the final release (Tails N), So > if these changes break upgrades, then upgrades from N to N+1 are > broken, regardless of whether we published N~rc1 or not. > > The only way to gain confidence in this area is to ship the changes in > *at least two* beta/RC releases and hope that enough users install the > first one, then automatically upgrade to the second one, then report > any issues in time for us to fix them in the final release (but those > fixes won't be field-tested).
That's what I thought as well :) > On the one hand, I would feel vastly > more comfortable if we manage to do this for the change we're talking > about here. OTOH, I don't know yet: > > - whether the code will be ready early enough to make this possible > (I'll have more visibility on this after the upcoming sprint, late > November); > > - whether we'll have the resources to publish two extra beta/RC > releases. > > So at this point, all I can promise is to *try* to make this happen. I trust you to be as careful as possible with such changes. >>> - 2020-04-07: Release 4.5 (major release) >>> >>> Automatic upgrade from 4.2 and newer (with overlayfs-based diff). >> >> This means that we'll have no major release until April (5 months), >> right? > > Right. > >> Imagine that we agree soon on some changes to Tails Greeter >> around #15635 (Unsafe Browser deanonymization), it wouldn't be shipped >> until April. > > Not necessarily. This year we had 9 months in a row with no major > release; we've advertised that we would have a more relaxed policy > than usual wrt. what qualifies for a bugfix release. AFAICT, this > worked quite nicely: a number of changes that don't really qualify as > "bugfix" made it into 3.x bugfix releases. > >> I'm starting to wonder whether the strict different between bugfix and >> major releases still makes sense. I understand that in practice for the >> release managers, the main difference is that major releases come with >> an RC and bugfix releases don't. Other than that, the review and merge >> work is done by the FT throughout the release cycle. And the >> effectiveness of RCs is not super clear anymore, as you've commented >> elsewhere. > >> If so, then new branches should maybe be categorized as needing an RC or >> not-needing an RC. And then maybe branches that don't really need an RC, >> could be merged into bugfixes release. > > I agree. I think that's basically what we did this year :) Indeed, I could find a couple of such changes in 3.11 and 3.13. > If we agree this is a good thing, we should probably update > our terminology accordingly at some point. IMO this can wait. > > Note that for some kinds of changes, we can gain confidence in changes > without going through our entire RC release process, for example by > issuing a specific call for testing. Right. -- sajolida Tails — https://tails.boum.org/ UX · Fundraising · Technical Writing _______________________________________________ Tails-dev mailing list [email protected] https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
