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.
For whatever reason, Asa, you seem to be missing the point. The point is not that 1.7 will be bad or that anyone is going to make it bad; on the contrary, everyone wants to see a good release. The point is that drivers should be making the decision about the stable branches significantly in advance and then publicizing that fact. It doesn't really matter whether the APIs are not any worse than they were in 1.4 or 1.0. They could have been significantly better, with an advanced warning. Drivers should have made the decision that 1.7 was going to be the stable branch and made Firefox, Thunderbird, and Camino make that work for them, not the other way around. You and the rest of drivers are letting the project be dictated without any timelines by three admittedly major Gecko implementors who just happen to be funded by the Foundation. The point everyone is trying to make is that the Foundation should be telling them when the stable branch should take place, not the other way around. If they needed features, they would've had months. At this point, all embeddors must live with APIs and core problems that might otherwise have been fixed.