Full Article Attached Mozilla 1.7 to Become New Long-Lived Stable Branch

Friday April 2nd, 2004

In a newsgroup posting, Asa Dotzler has announced that the Mozilla 1.7 branch will become the new long-lived stable branch, replacing 1.4. The stable branch is intended to act as a baseline for developers building Mozilla-based products, with critical bugs fixed on the branch as well as the trunk.

Mozilla Firefox 1.0, a new milestone of Mozilla Thunderbird, a new Camino release and several third party Mozilla based products will be based on Mozilla 1.7, so the Foundation is making efforts to ensure that it is high quality. To do this, the branching of 1.7 from the trunk has been delayed by a week to Friday 9th April and the final release of Mozilla 1.7 has been moved out a month to mid-May. Between the branching and the final version, three release candidates of Mozilla 1.7 will be made available, much like there were for Mozilla 1.0 and Mozilla 1.4. These release candidates will ensure that the 1.7 branch gets more testing and QA work.

While most welcome the fact that the aging 1.4 branch is to be replaced by something more modern, some developers have expressed concern that the decision to use 1.7 has been made so late in the release cycle.

#14 Re: Re: Re: Re: netscape

by jgraham

Saturday April 3rd, 2004 3:07 AM

You are replying to this message

> I dont understand why an api-stable branch, and a crash-stable branch for embedders, other projects need to be the same one..

Because embedders need to use the APIs? The whole point of a stable branch is not just that it is maintained, but also that it is the recommended base for people to build on.

In principle, there's no reason why Firefox needs to launch from an embedding-stable branch except that they will probably want to release security updates for 1.0 and only embedding stable branches are maintained.

> Basically, what I see is that you're advocating a developer-oriented release schedule instead of a consumer-oriented one.

That depends on who you consider the consumers of gecko to be. If you think of the consumers of gecko as being random members of the public who use Firefox and don't care about the internals at all, then that's a fair point. If you consider the projects which actually use gecko (not just sponsored projects but also people like <> and <> ) to be the consumers then it makes sense that one should require decent interfaces in one's stable releases.