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
