In order to drive us closer to conclusion I wanted to consolidate my understanding of the current plan in *early* draft form below. I propose we iterate on this here and take a final form to the wiki's/blogs for wider distribution.
So please edit, add questions, to the draft below...
Best,
Schrep
*** DRAFT PLAN **** *******************
Product Releases ----------------
Firefox 2.0.0.x and 3.0.x:
We'll continue the maintenance schedule we set with Firefox 1.5 - namely doing scheduled maintenance releases of Firefox 3.0.x and Firefox 2.0.0.x every 6-8 weeks. These releases will focus on security and stability improvements and cannot add new features, change UX, or break extensions unless it is required for security purposes or is otherwise critical. Since Firefox 3.1 is coming out so quickly after 3.0 I expect the size of these maintenance releases to be smaller than they have been for the 2.0.0.x series. Support releases for Firefox 2.0.0.x will terminate at the latest approximately 6 months after the shipment of Firefox 3. This coincides with the approximate ship date of Firefox 3.1.
Firefox 3.1:
There were a number of features that we held back from Firefox 3 because they weren't quite ready - but they were nearly complete. These include things like XHR, native JSON DOM bindings, ongoing performance tuning, awesomebar++, better system integration, etc. This along with the overall quality of Gecko 1.9 as a basis for mobile and the desire to get new platform features out to web developers sooner has lead to us want to do a second release of Firefox this year. This release would be date-driven and targeted at the end of 2008. Any features not ready in time will move to the next major release. This is currently planned to be based on Gecko 1.9.1 - but if there are solid technical reasons for breaking frozen APIs we will bump the version number to Mozilla2.
Firefox Mobile:
There are already devices shipping with early versions of Gecko 1.9 at the core. More are coming soon and we'll be releasing milestones of full branded versions of Firefox (with XUL and the Firefox team taking a lead in the user experience) later this year. This lines up well with Firefox 3.1 and a synchronized release schedule will make everything run more smoothly.
Firefox 4:
Firefox 4 will incorporate some of the more aggressive platform improvements in Mozilla2. It is far too early to set a shipping date but an initial target would be sometime in late 2009. Mozilla2 work has been underway for > 8 months
Platform Releases -----------------
Gecko 1.9.0.x:
Release date: By end of June 2008 Status: Stable Accepted Changes: Security, stability, performance, minor enhancements that do not change *any* exposed APIs. All changes must pass all regression tests and not regress performance. Development Tree: CVS Trunk Bugzilla Flags: blocking1.9.0.x Planning Center:
Gecko 1.9.1:
Release date: Beta stable summer 2008, production stable end of 2008 Status: In development Accepted Changes: Anything that doesn't break frozen API's. Passing unit tests and proof of no negative impact on perf from Talos required before check-in Development Tree: Hg mozilla-central - will move to a branch before end of summer 2008 Bugzilla Flags: blocking1.9.1 Planning Center:
Mozilla2:
Release date: Beta stable mid 2009 Status: In development Accepted Changes: Anything that doesn't regress functionality or performance Development Tree: Hg mozilla-central Bugzilla Flags: ? Planning Center: http://wiki.mozilla.org/Mozilla_2
Q&A ------
Q: I'm running a project based on Gecko and am confused as to weather to ship on 1.9.0.x, 1.9.1, or Mozilla2?
A: If you are shipping before Nov/Dec 2008 we recommend you ship on Gecko 1.9.0.x since it is the stable release. If your product is shipping after Dec 2008 we'd recommend you use Gecko 1.9.1.x since it will be stable by then. If you are shipping later you may want to consider Mozilla2
Q: Will Firefox 3.1 ship on 1.9.1 or Mozilla2?
A: We will start with 1.9.1 but if there is a compelling technical reason to break frozen APIs the drivers and module owners may decide to do so. If we break frozen APIs we will call it Gecko 2.0 and give fair notice.
----- Original Message ----- From: dev-planning-boun...@lists.mozilla.org
<dev-planning-boun...@lists.mozilla.org> To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> Sent: Mon May 19 15:55:37 2008 Subject: Re: What's next after Firefox 3 and Gecko 1.9?
Q: Will *all* APIs remain compatible between 1.9.1 and 1.9 as they were between 1.8.1 and 1.8?
A: No, only frozen APIs will remain compatible. I.e. we are free to change as many APIs between 1.9 and 1.9.1 as we did between 1.8 and 1.9
I think we gained very little as far as add-on compatibility goes by freezing as many APIs as we did. Only binary extensions have anything to gain by the level of freezing that we used, script-only extensions will not be affected.
I don't have any data on how many of our top-extensions have binary components though.
The cost of freezing all interfaces was quite high. It uglified new code a good bit as well as cost in performance and memory (though probably not to a significant extent).
This was sort of ok when the changes went in to a branch that is eventually going to die. It would suck a lot more to do that to mozilla-central where we'd have to clean up the mess later, or live with it forever.
Heh, so it would mean compat would be affected, then :)
I'm not saying we should or shouldn't feeze. APIs, and most definitely we should make the decision based on previous experience. Just wanted to make sure I understood the impact.
----- Original Message ----- From: dev-planning-boun...@lists.mozilla.org
<dev-planning-boun...@lists.mozilla.org> To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> Sent: Mon May 19 16:15:45 2008 Subject: Re: What's next after Firefox 3 and Gecko 1.9?
I think we gained very little as far as add-on compatibility goes by freezing as many APIs as we did. Only binary extensions have anything to gain by the level of freezing that we used, script-only extensions will not be affected.
I don't have any data on how many of our top-extensions have binary components though.
The cost of freezing all interfaces was quite high. It uglified new code a good bit as well as cost in performance and memory (though probably not to a significant extent).
This was sort of ok when the changes went in to a branch that is eventually going to die. It would suck a lot more to do that to mozilla-central where we'd have to clean up the mess later, or live with it forever.
/ Jonas
Mike Beltzner wrote: > What would that answer mean for add-on compatibility?
> cheers, > mike
> ----- Original Message ----- > From: dev-planning-boun...@lists.mozilla.org > <dev-planning-boun...@lists.mozilla.org> > To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> > Sent: Mon May 19 15:55:37 2008 > Subject: Re: What's next after Firefox 3 and Gecko 1.9?
> Q: Will *all* APIs remain compatible between 1.9.1 and 1.9 as they were > between 1.8.1 and 1.8?
> A: No, only frozen APIs will remain compatible. I.e. we are free to > change as many APIs between 1.9 and 1.9.1 as we did between 1.8 and > 1.9
> At least that's what I'm hoping the answer is :)
Mike Beltzner wrote: > Heh, so it would mean compat would be affected, then :)
> I'm not saying we should or shouldn't feeze. APIs, and most definitely we > should make the decision based on previous experience. Just wanted to make > sure I understood the impact.
> cheers, > mike
> ----- Original Message ----- > From: dev-planning-boun...@lists.mozilla.org > <dev-planning-boun...@lists.mozilla.org> > To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> > Sent: Mon May 19 16:15:45 2008 > Subject: Re: What's next after Firefox 3 and Gecko 1.9?
> I think we gained very little as far as add-on compatibility goes by > freezing as many APIs as we did. Only binary extensions have anything to > gain by the level of freezing that we used, script-only extensions will > not be affected.
> I don't have any data on how many of our top-extensions have binary > components though.
> The cost of freezing all interfaces was quite high. It uglified new code > a good bit as well as cost in performance and memory (though probably > not to a significant extent).
> This was sort of ok when the changes went in to a branch that is > eventually going to die. It would suck a lot more to do that to > mozilla-central where we'd have to clean up the mess later, or live with > it forever.
> / Jonas
> Mike Beltzner wrote: >> What would that answer mean for add-on compatibility?
>> cheers, >> mike
>> ----- Original Message ----- >> From: dev-planning-boun...@lists.mozilla.org >> <dev-planning-boun...@lists.mozilla.org> >> To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> >> Sent: Mon May 19 15:55:37 2008 >> Subject: Re: What's next after Firefox 3 and Gecko 1.9?
>> Q: Will *all* APIs remain compatible between 1.9.1 and 1.9 as they were >> between 1.8.1 and 1.8?
>> A: No, only frozen APIs will remain compatible. I.e. we are free to >> change as many APIs between 1.9 and 1.9.1 as we did between 1.8 and >> 1.9
>> At least that's what I'm hoping the answer is :)
I recently saw that overall about 10% of add-ons on the AMO site today have binary components.
More importantly I'm not sure how this 10% is weighted as far as actual use. I do know there are several in the top 20,50, 100... That would be the key to compatibility and the ability to recover from changes.
We should also plan on a lot longer ship cycle if we start introducing signficant levels of API changes. In Firefox 2 it took about a 2-3 month push to get extension compatibility to an acceptable shipping level, and for the most part it was just a testing and version compatibilty rev'ing exercise. In Firefox 3 it was more like a 5-6 month push, with a lot more work, and with a lot more people working hard to make that happen. In the end we didn't quite get to the level of extension compatibility we had for Firefox 2, but we came pretty close.
This is not to say we should/should not freeze api's. This is to say that the number and area of API changes is one of the factors that will determine a realistic schedule, since we need a reasonable level of extension compatibility to ship any release.
The best thing that could be done is to map out *which* APIs might change, then do a bit of estimating on what the impact of the changes might be on extension compatibility and the back end of the schedule. Where is a good area to start mapping out the proposed changes?
The other thing is that if we are going to change APIs, we need to get this work done early, and enforce some early API freeze dates. Dragging the API changes out into late betas also lengthens the period needed to get extension developers working on compatibility, and will turn out to lengthen the overall shipping schedule.
Extension compatibility also relies on a wide variety of areas beyond binary compatibility, so freeze dates ought to account for all those areas.
Jonas Sicking wrote: > Yes, compat would definitely be affected. But I believe the benefit/cost > ratio is low enough that it's not worth it.
> / Jonas
> Mike Beltzner wrote:
>> Heh, so it would mean compat would be affected, then :)
>> I'm not saying we should or shouldn't feeze. APIs, and most definitely we >> should make the decision based on previous experience. Just wanted to make >> sure I understood the impact.
>> cheers, >> mike
>> ----- Original Message ----- >> From: dev-planning-boun...@lists.mozilla.org >> <dev-planning-boun...@lists.mozilla.org> >> To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> >> Sent: Mon May 19 16:15:45 2008 >> Subject: Re: What's next after Firefox 3 and Gecko 1.9?
>> I think we gained very little as far as add-on compatibility goes by >> freezing as many APIs as we did. Only binary extensions have anything to >> gain by the level of freezing that we used, script-only extensions will >> not be affected.
>> I don't have any data on how many of our top-extensions have binary >> components though.
>> The cost of freezing all interfaces was quite high. It uglified new code >> a good bit as well as cost in performance and memory (though probably >> not to a significant extent).
>> This was sort of ok when the changes went in to a branch that is >> eventually going to die. It would suck a lot more to do that to >> mozilla-central where we'd have to clean up the mess later, or live with >> it forever.
>> / Jonas
>> Mike Beltzner wrote:
>>> What would that answer mean for add-on compatibility?
>>> cheers, >>> mike
>>> ----- Original Message ----- >>> From: dev-planning-boun...@lists.mozilla.org >>> <dev-planning-boun...@lists.mozilla.org> >>> To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> >>> Sent: Mon May 19 15:55:37 2008 >>> Subject: Re: What's next after Firefox 3 and Gecko 1.9?
>>> Q: Will *all* APIs remain compatible between 1.9.1 and 1.9 as they were >>> between 1.8.1 and 1.8?
>>> A: No, only frozen APIs will remain compatible. I.e. we are free to >>> change as many APIs between 1.9 and 1.9.1 as we did between 1.8 and >>> 1.9
>>> At least that's what I'm hoping the answer is :)
Jonas Sicking wrote: > I think we gained very little as far as add-on compatibility goes by > freezing as many APIs as we did. Only binary extensions have anything to > gain by the level of freezing that we used, script-only extensions will > not be affected.
Mozilla seems to have several different kinds of APIs so I'm not clear on what freezing/compatibility issues are being discussed. But late in FF3, the effective API for extensions changed because of changes in security model. At least for Firebug this had far more impact than any reworking of APIs I can imagine. Similarly the new https requirement on extensions. So if some good comes from evolving the APIs, its seems like it would not be significant additional cost for extensions.
chris hofmann wrote: > The best thing that could be done is to map out *which* APIs might > change, then do a bit of estimating on what the impact of the changes > might be on extension compatibility and the back end of the schedule. > Where is a good area to start mapping out the proposed changes?
Can we turn that around? Would it be possible, given an interface, to scan AMO for binary extensions that use that interface in their binary blobs?
> The other thing is that if we are going to change APIs, we need to get > this work done early, and enforce some early API freeze dates.
The problem is that API changes are not the end in and of themselves, usually. They are often needed, for our core "internal" APIs to address other issues that come up. No one is suggesting changing APIs for the fun of it, I don't think.
For example, note that if a blocker issue comes up in RC1 right now that can be most easily fixed by changing nsIContent we would change nsIContent before we ship final. The question is whether 1.9.1 should be held to a higher bar than this (as 1.8.1 was).
