User talk:ChrisHofmann/QuarterlyReleases: Difference between revisions

One would be to understand the weak points of the development model, and watch for the return of the same side effects. More test automation, and better version control systems than we had in 2001-2004 will probably help to combat the effects developers taking on smaller projects to match quarterly releases. But, the web is still hard. Some significant projects may require new strategies for getting the kind of field testing abnd longer beta cycles needed to ship major features in core gecko.  

The code complexity issues associated with lots of extra build and runtime flags to be able to turn off features and/or development them "under the hood" also deserves so thought. Figuring out plans for cleaning these up after their useful lifetime ends and other strategies also need consideration.  

The history above shows a slowly increasing cycle over time as it was harder and harder to maintain the rapid pace. We can also find ways to measure and possibly combat this effect as we try to get back on a faster pace.  

Getting back on a faster pace also will have challenges. It took awhile to ramp to the fast pace of 2002, and we learned over time that for every 1 month of serious development work on the trunk at least 1 to 1.5 months have been required in beta to shake out problems. This rule seems to apply to both short development cycles and long ones like with Friefox 3.0, and in the cases as we continue to roll in features over a consecutive betas.