Proposed Release Plan changes

Justin Wood (Callek) callek at gmail.com
Fri Aug 10 17:44:23 UTC 2012


Mark Banner wrote:
>> 1. What are the perceived pros and cons by not adopting the rapid
>> release model?
>
>   * Stability, we don't have significant gecko changing under us every
>     six weeks, nor will we have large Thunderbird changes

CON: But you'll have larger range of changes from ESR to ESR and harder 
to pinpoint regression ranges.

>       o We don't have to do so much regression testing continuously

Incorrect, SeaMonkey will need the same work if someone breaks things. 
(so 'we'==='community' in this case)

>       o There's a greater range of time where our changes can get testing

Incorrect if you account that SeaMonkey uses the same code.

>       o Less risk of regressions that are found after each release, so
>         less likely to need the x.0.1 releases that we've been seeing

Increasing the timeframe, and decreasing users on a release, doesn't 
change the RISK of regressions, it does however INCREASE the risk that 
it won't be caught before release. And increases the pain of 
finding/fixing the regression.

>       o Regressions that have been caused by gecko, don't necessarily
>         have to be fixed straight away before the next cycle, but can be
>         left to run a bit longer

Again, Incorrect if you account for the fact that SeaMonkey is still 
doing releases.

>       o It gives a bit more stability to extension authors and users, as
>         mentioned in the original announcements

ALL the above is true for any code specifically mail/ (or chat/) but not 
the shared mailnews/

-- 
~Justin Wood (Callek)



More information about the tb-planning mailing list