intrigeri:
> Here's my proposal (see below for the detailed reasoning):
>
> * 2018-01-23: Release 3.5 (bugfix release) — anonym is the RM
>
> * 2018-03-13: Release 3.6 (major release) — bertagaz is the RM
>
> * 2018-05-08: Release 3.7 (bugfix release) — bertagaz is the RM
>
> * 2018-07-03: Release 3.8 (bugfix release) — intrigeri is the RM
>
> * 2018-08-28: Release 3.9 (major release) — anonym is the RM
> → includes ESR60 + VeraCrypt support + Additional Software Packages
>
> * 2018-10-23: Release 3.10 (bugfix release) — anonym is the RM
>
> * 2018-11-27: Release 3.11 (major release) — anonym is the RM
> → the most likely first Tails release based on Debian testing,
> *if* we decide to try it out.
Works for me I think. Maybe I'll be able to combine the user testing for
both Additional Software and VeraCrypt in a single sprint :)
> Detailed reasoning
> ==================
>
> [...]
>
> And I've (finally…) changed my mind recently
> wrt. the cost/benefit of sticking to the odd=bugfix/even=major
> convention, after I heard a Tails contributor explaining in a talk
> that "we'll skip 3.4 because the project lacks resources".
Uhh, interesting fact :)
> I think
> I was the only one explicitly pushing for this scheme so I bet
> (almost?) everyone will be happy to switch to meaningless — but less
> confusing — incrementing version numbers, starting with Tails 3.5.
I also like the odd=bugfix/even=major scheme, in theory but in practice
the Firefox schedule leads to confusing numbering every year or so.
I have no strong opinion but it's a good idea to try version numbers
that are meaningless to us and see how it works for us this year.
