To clarify... will we still have 6 weeks of feature development, then 6
weeks of stabilisation for version n before we officially start feature
development of version n+1  as per
https://wiki.mozilla.org/FirefoxOS/devlifecycle? It's just that the names
of the milestones have changed to be more in line with the terminology our
partners use?

So a stabilisation branch will still be created at the "Feature Landing"
date and continue to exist until "General Availability", it's just that the
new list of milestones is more explicit about what happens after "Feature
Complete" in that we expect to be continuing to work on some bugfixes for
version n for at least six weeks after starting feature work for version
n+1.

As a loose analogy this feels quite similar to Firefox versions going from
Central to Aurora (Feature Landing), Aurora to Beta (Feature Complete) and
Beta to Release (Code Complete), except that Firefox OS only has a release
every 12 weeks because version n+1 doesn't start development until version
n has gone to Beta (Feature Complete). And OEMs/ODMs will start their
testing after Beta goes to Release (Code Complete).

This means that in theory Firefox OS now explicitly has the same 1:2 ratio
of feature development to stabilisation as Firefox, except that in practice
some n+1 feature development does happen on master in the extra six weeks
after version n branches and some stabilisation does happen after Code
Complete so it's closer to 2:3.

Ben


On Wed, Apr 30, 2014 at 11:35 PM, Lawrence Mandel <lman...@mozilla.com>wrote:

> I'd like to share some changes to the release milestones for B2G 2.0. Our
> intention is to get to a predictable release schedule with a defined path
> to shutdown development of a release. Additional work will happen to define
> the General Availability (GA) milestone and how we can effectively work
> with our partners to support their test cycles while meeting Mozilla's
> needs to work on newer releases.
>
> I know that we've been through a number of milestone/schedule changes in
> the past. This naturally begs the question why will this time be different?
> We have put in place tracking and criteria in order to have meaningful
> conversations about the progress of the release early and often. (These
> conversations will happen at least weekly starting at week 2 in the cycle.)
> The point of these conversations is to identify issues and take corrective
> action early.
>
> Below is the short version of the milestone definitions and a link to the
> longer version on the wiki. There is also a simple mapping of previous
> milestones and how they roughly map to the 2.0 milestones.
>
>
> The short version:
> FEATURE LANDING (FL)
> 6 weeks after development starts
> all feature work must be complete by the this date
> this milestone marks the beginning of the stabilization phase of the
> release
>
> STRING FREEZE
> target is FL with minimal string changes landing after FL
>
> FEATURE COMPLETE (FC)
> target 6 weeks after FL
> hard cut off for feature work FL exceptions
> requires QA sign-off
> indicates the build is ready for chipset vendor testing
>
> CODE COMPLETE (CC)
> target 6 weeks after FC
> zero blockers left from Mozilla and chipset vendors
> indicates the build is ready for OEM/ODM testing
>
>
> The longer version:
> https://wiki.mozilla.org/Release_Management/FirefoxOS/Release_Milestones
>
>
> Rough mapping of previous milestones:
> 2.0 FL = 1.4 FC
> 2.0 FC = 1.4 RTP
> 2.0 CC = 1.4 CF
> 2.0 GA = 1.4 TA
>
>
> Please respond to dev-b2g with questions.
>
> Lawrence
> _______________________________________________
> dev-gaia mailing list
> dev-g...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to