AOL to Release New Netscape Update in Early Summer
Tuesday March 30th, 2004
The Inquirer is reporting that America Online is to release a new version of the Netscape browser. The upgrade will be a "'point' release based on the latest Mozilla code" and "will be made available in the very early summer timeframe." Speculation that an update was in the works began last week, when the San Francisco Bay Area's Mercury News paraphrased an AOL spokeswoman as saying that "there will be future versions of Netscape that are essentially repackaged upgrades of Mozilla."
The confirmation that a new Netscape release is on the way does not indicate that AOL is planning to provide any further development or financial support to the Mozilla project. Indeed, no AOL employees are paid to work on Mozilla and we can expect this latest version to be even more similar to Mozilla than previous releases. The more intriguing question is what made AOL change its mind about shelving the veteran browser.
#44 Re: Re: Re: Re: Re: Re: New stable branch?
Thursday April 1st, 2004 1:58 PM
You are replying to this message
"I have no problem with stabilizing 1.7 crash-wise and such. We should do that. I have problems with declaring it a long-lived API-stable branch. I have MAJOR problems with the fact that we are letting vendors force our hand as to what will be a long-lived stable branch and what won't be. That should be a decision mozilla.org makes. Vendors can have input into it, sure. But then they should provide that input at an early enough date that mozilla.org can adjust accordingly."
And when a significant number of the vendors/projects (for example, Firefox, Thunderbird, Camino, and others) say "we're shipping a 1.7 based product that we intend to maintain for some time" then mozilla.org should just say "too bad, our efforts are on the 1.8 branch that no one intends to use"? That doesn't seem terribly productive to me. We can make 1.8 as maintainable as you like but if the products that are going out to millions of users are shipping (and shipping updates/point releases) off of 1.7, then it just doesn't matter how maintainable or api complete 1.8 is.
What would you propose we do? We could cancel the 1.7 release and branch so they _couldn't_ use it (though I suspect we'd just have a Firebird 1.0/Thunderbird/Camino branch in its place). Maybe we could change our license so that people were disallowed from shipping end-user products from code branches that the developer community didn't like?
In a perfect world we'd have known that these projects 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). It's considerably slower, it's missing some key new features, and it's not going to be 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 and ship updates/point releases. We can work with that or we can not work with that.