User talk:ChrisHofmann/QuarterlyReleases
Some thoughts on Quarterly Releases.
Contents
Back To The Future?
Those that have been around on the project for a while should remember that between 2000-2004 the Mozilla Project pursued a development plan based on a quarterly release schedule.
The outline for this plan was formulated in http://www-archive.mozilla.org/roadmap/roadmap-25-Sep-2000.html (see: New Milestones).
A couple of points in that plan were key:
- We may well slip every one of these milestones somewhat, but we're aiming at quarterly milestones.
- We do not propose to be exclusively date-driven, or else the Mozilla community may balk at any pretense that Mozilla 1.0 deserves the "1.0" version string.
- But we emphatically intend to produce regular milestones: the trains will run more or less on time!
How did we do on execution?
It took a while to get things off the ground, but as soon as death march to produce netscape 6/mozilla 0.6 finished the plan began in earnest. It produced a nearly monthly to quarterly cadence of releases that reached an audience of browser enthusiasts that grew to around 300,000, and by mozilla 1.0 to over 1 million people. The plan even accommodated re-writes and landing of major components like the graphic library, and integrating bi-di into layout.
The results of the rapid fire monthly/quarterly releases became the basis for netscape releases that shipped to multi-millions of users after they went though a lot of hard pounding, analysis of crash data,. feedback and qualification by the growing mozilla community.
Over time the process was refined and improved so the "multi-million distribution releases" shipped closer and closer, and eventually in parallel to the "browser enthusiast releases."
Chart below does not reflect still even more minor out-of-band releases needed in response to security issues.
mozilla milestone
releases shipped to larger scale wider distribution releases
100-300k (multi-millon user releases)
browser enthusiast
| |
V V
<-psm 2001-01-09 0.7 <-pop-up blocking on hidden pref, new windows cascade 2001-02-14 0.8 <-libpr0n neckomajor theme reorg 2001-05-01 0.9 <-bi-di 2001-06-07 0.9.1 -> N6.1 – 2001-08-08 (based on 0.9.2.1) <-lock icon links to page security info (larry's grandfather) 2001-06-27 0.9.2 <-1.9.3 now more stable than N4.78, turbo mode start-up on hidden pref 2001-08-02 0.9.3 <--turbo enabled by default 2001-09-12 0.9.4 -> N6.2 – 2001-10-30 (based on 0.9.4.1) -> Compuserve7 2002-04-26 (based on 0.9.4.2) <-tab browser 2001-10-12 0.9.5 <-print preview 2001-11-20 0.9.6 <-dom inspector 2001-12-20 0.9.7
<-native widgets in UI 2002-02-01 0.9.8 <-mathml jsd, truetype fonts 2002-03-11 0.9.9 2002-05-23 1.0 RC3 2002-06-05 mozilla 1.0 -> N7.0 – 2002-08-29 (based 1.0.1) <-dhtml perf, major update to jsd 2002-08-26 1.1 <-type ahead find 2002-11-26 1.2
<-image auto resizing 2003-03-12 1.3 <-NTLM authentication, 1000's of bug fixes 2003-06-25 1.4 -> N7.1 – 2003-06-30 (based on 1.4) 2003-10-12 1.5 first foundation produced release
<-CSS2.1 (computed values are inherited) 2004-01-15 1.6 basis for Firefox 0.8 2004-02-09 <-smooth scrolling, ftp upload 2004-06-17 1.7 -> Netscape 7.2 – 2004-08-24 (based on 1.7) -> Firefox 1.0 - 2004-11-09 (based on 1.7)
A Shift Away From Monthly/Quarterly Releases
After the release of Firefox 1.0 the consensus was to move away from these frequent monthly/quarterly cycle to one aligned with firefox major release cycles
1.8 2005-09 1.5b1 -> firefox 1.5 Nov 29, 2005
1.8.1 2006-06 2.0b1 -> firefox 2.0 Oct 24, 2006 1.9 branch 2006-10?
Aug 23, 2007 a1
Nov 19, 2007 b1 -> firefox 3.0 June 17, 2008
1.9.1 -> firefox 3.5 June 30th, 2009
Why Did We Change the Development Process?
IIRC, a couple of the key reasons for moving away from the monthly/quarterly cycles grew out of a few of development problems that had emerged.
- The monthly, and then quarterly cycle were not conducive to taking on larger and longer core development projects that didn't lend themselves to long term parallel development on project branches and/or and landing, testing, and shipping to lots of people within a 1-3 month cycle. The result of 3 years of this rapid fire releases was to create incentives for developers to take on smaller, and less ground breaking work and discourage the work on harder and more complicated improvements.
- The other criticism of the 2001-2004 development process was about having to develop code with build flags and run time prefs to turn off and on features. Over time this led to extra unwanted complexity in the code.
- It was easier to market and make noise about big bang releases with a larger collection of features.
- Others may recall more points that influenced the decision for the shift.
Using History as a Guide
So whats the value of this historical view?
One would be to understand the weak points of the development model, and watch for the return of the same side effects.
More build and 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 and longer beta cycles needed to ship major features in core gecko.
The code complexity issues associated with lots of extra build and run-time 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 also 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 2001, 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 Firefox 3.0, and in the cases as we continue to roll in features over a consecutive betas. Once the development cycle starts to increase it gets harder and harder to get the cat back in the bag. Shipping off trunk frequently helps to stay out of the vicious circle of longer development periods requiring longer betas.
Impact On Quality
When I hear someone suggest that shipping quarterly releases means that we need to change/lower expectations for quality to meet a faster paced shipping schedule, it's like fingernails on a blackboard to my ears. Probably the same for mevans and many others as well. '
The history above shows that a monthly-quarterly release schedule can actually have a dramatic and positive effect on quality, where the quality level of a disastrous Netscape 6/Mozilla 0.6 was incrementally transformed into increasingly better milestones that also lead to successful Mozilla 1.0 and then Firefox 1.0 releases.
We should demand ever increasing quality of the new faster paced release plan.
Scaling the size of the web from where it was in 2004 we should be able to turn those 300,000-3 million users that helped bring Firefox to its initial release to a larger community of 10 million that will give us more and faster feedback on short development cycle releases. We should stop rolling our eyes at this goal and start acting to make it happen. The ground work for this has been laid in the Firefox 4 beta program, and needs to continue. The 10 million goal is achievable.
Success means 10 million browser enthusiasts get polished views our our new browser technology enhancements and a view into the amazing work we will do, but the other 400-500 million other firefox users will get our software when it's rock solid, community tested, and community approved and at a major update pace that may feel more comfortable for them.
What did the development plans look like
The were simple but effective documents to set the stage for priority setting, triage, and release criteria.
development plan to achieve 1.0
http://www-archive.mozilla.org/roadmap/mozilla-1.0.html
what was achieved documented at
