Hi,
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). 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.
>> - 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 :)
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.
Cheers,
--
intrigeri
