MozillaReleasePlanning

From MozillaWiki
Jump to: navigation, search

We are beginning the transition from using Seamonkey as our primary Gecko testbed to using Firefox and Thunderbird. Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey milestone, we'll be shipping a Firefox and Thunderbird 1.1 testers-only preview (calling it "alpha" for now). This preview for Firefox and Thunderbird will fill the release slot that was formerly occupied in the roadmap by "Mozilla 1.8 Beta 2".

We were scheduled to freeze for 1.8 Beta 2 on March 15th at midnight but we're not ready for that yet. There is more work, front-end and back-end (cleaning up regressions from new features, completing the heavy lifting of the Thunderbird localization re-organization, fixing key bugs, analyzing and fixing topcrashers, getting XULRunner further along, etc.) that needs to happen before we're in a position to ship the Firefox and Thunderbird 1.1 alphas. We estimate that we can get into shape for the alpha releases in the next 3 to 5 weeks so we're planning on extending the open Mozilla 1.8 Beta 2 development period for at least 3 more weeks.

As we get closer to that point, we'll announce the actual freeze date for 1.8 beta 2/Firefox&Thunderbird 1.1 alpha. All changes landed after the freeze date will require drivers' approval and will be limited to the kind of changes necessary to get the 1.1 testing previews shipped.

After we ship the 1.1 alphas, we still have work to be done before we're at feature complete (calling that "beta" for now) for the apps, and standing up the XULRunner embedding story. The question arises whether we should branch and do all of this heavy lifting on the branch, to get out of the way of Gecko 1.9 work, or try to stay on the trunk for another cycle and do the work there.

If we branch early, we're splitting resources, both developer and QA and we're splitting focus. This was a most unpleasant experience on the 1.7 branch for both the branch and trunk folks. There is probably no way to get around a month or two on the branch, but three months or more sounds like pain.

If we decide to branch later, then the tree would stay closed after the alphas and until we ship Firefox and Thunderbird 1.1 beta (and possibly a preview of XULRunner) and digest that feedback. During that tree closure, we'd be focused on responding to the feedback from the 1.1 alphas and fixing both core Gecko and XULRunner issues as well as Firefox and Thunderbird app issues. Being frozen on the trunk after beta, which is also the freeze for localizable strings, would give our L10N teams a chance to get their locales completed or nearly completed on the trunk before branching. This could save them considerable time as compared to branching sooner.

Staying closed on the trunk makes little sense if we can't all rally around the tasks that need doing for the 1.8 branch and releases (Firefox, Thunderbird, and XULRunner).

We realize that we've got a lot of big work ahead for the 1.9 cycle and not everyone working on Mozilla is working on code directly related to the 1.8 releases so in order to answer the question of when to branch, it would be a great help if you all could note here the work you're doing and your preference for early or later branching. If most are ready to jump on 1.9 work, then we'll branch sooner. If most want to work to make 1.8 releases as solid as possible, then we'll branch later.

Here are two possible roadmap diagrams. The first shows a quick branch with overlapping trunk and branch releases and the second diagram shows a longer trunk freeze with a shorter stable branch before 1.8 final products.

Thanks to Boris for adding the nifty table under the images.

Branching Early rm-2005-03-14.png
Branching Late rm-2005-03-14-alternate.png
Name Plans
Asa Driving the 1.1 releases and helping out how ever I can with XULRunner.
Boris Zbarsky Currently I'm pretty busy with reviews and cleaning up remaining regressions from the 1.8a cycles. The only 1.9-type thing I'm really working on currently is bug 286000, but I also have some reasonably short-term plans to make the hacks that were landed for aviary for "force open in tab" general enough that embedders can implement equivalent functionality. Other than that, I keep meaning to spend some time on the reflow branch. Given all that, and the amount of work I'll probably end up doing on interface-freezing and the like before 1.8, I think I'm happier with not branching while we have heavy back-end lifting pending and instead perhaps focusing a tad more on the bugs that are blocking the 1.8 betas (and on sorting out which bugs those are).
Daniel Brooks I say branch later.
Bernd I am focused on stability work in table code. Given the long time without a real freeze I would prefer the late branch taking the trunk as a hostage to get the beast stable. This would help both trunk and branch folks on a long run. Or reverse formulated branching from a unstable trunk creates unecessary work on porting.
Robert Kaiser From the L10n point of view, I think that bug 286108 (Thunderbird source L10n) should be completed before branching, so that we don't have to backport those CVS moves to trunk again. From my view in SeaMonkey project, forcing people to work with the "stable" code a bit longer (by branching late) and not opening trunk too soon sounds like a good idea as well, as we need to bundle our resources to get a release out.
Wan-Teh Chang Please update http://www.mozilla.org/roadmap.html#milestone-schedule to reflect the three more weeks of Mozilla 1.8 Beta 2 development period you are considering.
Axel Hecht I have quite a bit of design work to do in the area of RDF, I'm not sure if I can resurrect some of that in the 1.8 cycle. I personally don't have a lot of issues moving that development on a branch myself, so that we have something to land in alpha. Smells like I'm fine with both plans, though the late freeze is going to be smoother AFA l10n is concerned. We could use some of that, I bet, I see stormy parts in that water anyway. Technically ones only, but still.
Zbigniew Braniecki Toolkit source l10n should be ready in 5 weeks. There is amount of work that need to be done by localizers to prepare current CVS localization to be used by Thunderbird. I'd love to see Thunderbird 1.1 beta l10n.