intrigeri:
> Here's an initial proposal, optimized towards minimizing the number of
> major releases we have to do, while meeting our sponsor deadlines.
>
> My goal here is that we identify bugs in this draft:
>
> - 2019-10-22: Release 4.0 (major release)
>
> - 2019-12-03: Release 4.1 (bugfix release)
>
> - 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?
> - 2020-02-11: Release 4.3 (bugfix release)
>
> Automatic upgrade from 4.2, using the new upgrade system (but still
> with aufs-based diff).
>
> From now on, users of Tails << 4.2 must first automatically upgrade
> to 4.2, before they can automatically upgrade to the current 4.x.
> Alternatively, they can do a manual upgrade. UX will tell RMs which
> of these options we should advertise.
>
> - 2020-03-10: Release 4.4 (bugfix release)
>
> Automatic upgrade from 4.2 and newer (still with aufs-based diff).
>
> - 2020-03-21: potential emergency release that traditionally follows pwn2own
>
> - end of March 2020: Release 4.5~rc1
>
> MUST switch to overlayfs (#8415).
>
> If GRUB and Secure Boot are ready to ship as well: awesome!
> Otherwise, we'll need another major release by the end of July.
>
> Automatic upgrade from 4.2 and newer (now with overlayfs-based diff).
>
> - 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? Imagine that we agree soon on some changes to Tails Greeter
around #15635 (Unsafe Browser deanonymization), it wouldn't be shipped
until April.
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.
Other than that, I'm fine with the schedule :)
--
sajolida
Tails —
https://tails.boum.org/
UX · Fundraising · Technical Writing
