Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion What's next after Firefox 3 and Gecko 1.9?

Path: g2news1.google.com!news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.mozilla.org!news.mozilla.org.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 19 May 2008 19:20:56 -0500
Return-Path: <chofm...@meer.net>
X-Original-To: dev-plann...@lists.mozilla.org
Delivered-To: dev-plann...@lists.mozilla.org
Date: Mon, 19 May 2008 17:19:12 -0700
From: chris hofmann <chofm...@meer.net>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Jonas Sicking <jo...@sicking.cc>
Subject: Re: What's next after Firefox 3 and Gecko 1.9?
References: <mailman.204.1211239452.6183.dev-planning@lists.mozilla.org>
	<GJadnZrJnrB_kK_VnZ2dnUVZ_hKdnZ2d@mozilla.org>
In-Reply-To: <GJadnZrJnrB_kK_VnZ2dnUVZ_hKdnZ2d@mozilla.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Canit-CHI2: 0.50
X-Bayes-Prob: 0.5 (Score 0, tokens from: )
X-Spam-Score: 1.20 (*) [Tag at 5.00] APOSTROPHE_OBFUSCATION,PORN_RP_SUCK
X-CanItPRO-Stream: default
X-Canit-Stats-ID: 421502 - b3a3683647e7
X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13
X-Virus-Scanned: by amavisd-new
Cc: dev-plann...@lists.mozilla.org
X-BeenThere: dev-plann...@lists.mozilla.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dev-planning.lists.mozilla.org>
List-Unsubscribe: <https://lists.mozilla.org/listinfo/dev-planning>,
	<mailto:dev-planning-requ...@lists.mozilla.org?subject=unsubscribe>
List-Post: <mailto:dev-plann...@lists.mozilla.org>
List-Help: <mailto:dev-planning-requ...@lists.mozilla.org?subject=help>
List-Subscribe: <https://lists.mozilla.org/listinfo/dev-planning>,
	<mailto:dev-planning-requ...@lists.mozilla.org?subject=subscribe>
Newsgroups: mozilla.dev.planning
Message-ID: <mailman.208.1211242856.6183.dev-planning@lists.mozilla.org>
Lines: 123
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 63.245.208.166
X-AuthenticatedUsername: NoAuthUser
X-Trace: sv3-bfbCUhweJ0Jv1S+JXZTeuPGRcf8imxg2MNboEv8xb5PXZnUUFWTQeNlVfo0ilzppGjUemF3lcJCExLE!rfcg2h5jj3v6bjKF7KiOa7ya0sAfGn4X1n2BOSEuNEVAwF0n4NM4gxHUVSYpIFbx91cAURGxsAb2!jBs7N3nqFBjKgygPCDC1i3eAXPbah7iP
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.39


To add some data:

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.


-chofmann

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
>>> _______________________________________________
>>> dev-planning mailing list
>>> dev-plann...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-planning
>>>       
>> _______________________________________________
>> dev-planning mailing list
>> dev-plann...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-planning
>>     
> _______________________________________________
> dev-planning mailing list
> dev-plann...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>