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.
#36 Re: SNAFU
Monday April 5th, 2004 7:38 PM
You are replying to this message
something of a repost:
In a perfect world we'd have known that _all_ of the mozilla.org products (and other non-mozilla.org products) were going to end up on the 1.7 branch with advanced notice of several months or more. We'd have announced this far and wide and developers would have had more opportunity for getting APIs finished out and major features or bugs fixed. But we're not in a perfect world. Things didn't start to line up until right around the time of developer day. Projects (Firefox, Thunderbird, SeaMonkey, Camino, others) converged on 1.7 late in the game. Part of the reason they converged on 1.7 is because 1.4 is so outdated (having branched about a year ago), considerably slower, missing some key new features, and it's about to be retired (no longer maintained). Those projects all wanted something newer than 1.4, they're not waiting another 3 or 4 months for 1.8, and they need (and will contribute to) a stable branch from which they can ship releases and ship updates/point releases.
We have limited resources. A major hunk of our resources (pretty much all of the Mozilla Foundation paid staff) are going to be devoted to making 1.7 something that's stable, fast, functional, and useful to products delivering Gecko into the hands of millions of users. We cannot ship a lame Mozilla 1.7, a broken Firefox 1.0, hosed Camino or Thunderbird releases. All of those apps, bearing the name and reputation of mozilla.org must be of high quality and that's going to take some effort. They're also going to need to ship updates/point releases from that branch and that means the branch will need to be maintained. The math isn't too difficult. That simply doesn't leave us with resources to also maintain a 1.8 or a 1.9 long-lived branch for other embedders. If other embedders want to maintain a second branch, they can certainly contact drivers with a plan and information about the resources they're willing to commit.
I wish that things had come together months earlier and that we would have had more communication, but this is where we are. We have _all_ of the mozilla.org applications set to make important releases from the 1.7 branch. We have other products set to ship off of the 1.7 branch. These releases come at a pivotal time and will likely garner quite a bit of press (at least I expect that Firefox 1.0 will) so they really must be of high quality and I'm confident that they will be. Yes, we could have done a better job at getting this organized and communicated to the developers working on the core codebase. I'll accept some of the blame for this coming off less than ideally, though I am just one of about a dozen drivers from multiple organizations, so don't assume that because I'm the lucky guy that gets to post the news that I'm the only person involved in the decisions or planning.
If you've got an application that depends on APIs that you know are worse than they were in 1.4 or you know of bugs that make Mozilla 1.7-based products worse than 1.4-based products, how about spending some of your time delivering those specifics (even better if they come with patches) to <email@example.com> rather than complaining at mozillazine. This release cycle isn't over yet and there's still time to get some kinds of changes into this branch. If you've got resources to maintain additional Mozilla branches to meet your product needs, then how about sending mail to <firstname.lastname@example.org> rather than posting complaints at mozillazine.