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
mozilla.dev.planning
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Firefox 3.1: Beta 3 proposal
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Mike Beltzner  
View profile  
 More options Nov 25 2008, 11:48 am
Newsgroups: mozilla.dev.planning
From: Mike Beltzner <beltz...@mozilla.com>
Date: Tue, 25 Nov 2008 11:48:34 -0500
Local: Tues, Nov 25 2008 11:48 am
Subject: Re: Firefox 3.1: Beta 3 proposal
Print | View thread | Show original | Report this message | Find messages by this author
On 25-Nov-08, at 11:06 AM, Christopher Blizzard wrote:

> We still want to make the promise to add-ons developers that beta2
> will be "stable enough" to start mass converting add-ons, and your
> email does mention this.

Yes, this is an important plank of both the rationale and the process!

> It follows in my mind that by making this statement we're committing
> to keep major functionality after beta2.  For example, it would be bad
> if someone wants to take advantage of DOM worker threads in their
> add-on, and we pull it before beta3.

Part of the Beta 2 criteria was that anything that made it into that  
beta was being accepted as our set of technologies to ship in Firefox  
3.1. I concur that we're making this implicit promise, and will make  
sure that's a point drawn clearly on the call.

Of course, if it turns out that worker threads puts our overall  
release at risk, or introduces massive-scope security problems, etc,  
we might have to re-evaluate. We're never going to ship something  
unless it's ready. However, because we're making a commitment to our  
add-on developers, it wouldn't be removed lightly or without  
evaluating alternatives.

> I just want to call this out as something that's an implicit promise
> we're making.  If we're not ready to make that promise we should make
> sure we say so.

This is a little tricky, as I don't want to walk down the route where  
we're making platform-promises to anyone. Firefox is the product  
that's driving here, and we'll do what's best for Firefox. Wherever  
possible we will do things to work with and make things easier for our  
add-on community, but we can't get into a position where we limit our  
ability to make required changes to the codebase in order to serve  
that portion of our community. I'm perhaps focusing on a semantic nit  
here (about what "required") means, and indeed it would have to be a  
pretty major issue to appear at this point to make us change course,  
but I don't want to make blanket promises that handcuff us, either.

cheers,
mike


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google