Although it is true that we are in a development phase now, we need to
start being more careful about breaking changes. People are attempting
to use our stuff now, and it is hard for them to keep up with our
build rate. If we break things every week, we'll burn off our early
testers, which would be bad.

I've asked for changes to avoid breakage in some reviews, but I forget
sometimes, so I want to make a general request now.

What I would like to see us do for the typical case is:

- If people use the old API and it is easy to do, continue supporting it.
- Change the docs to only mention the new API
- Add a comment to
http://code.google.com/p/chromium/issues/detail?id=16356 reminding us
to remove the deprecated API at 1.0
- When we send out the extension visible changes mail each week,
mention the deprecated APIs in it

To be clear, I'm not suggesting we should never break things at this
point, just that in cases where it is easy to avoid breakage that we
should do that.

As an example, Matt recently renamed chrome.self to chrome.extension
and just kept an alias at chrome.self. For Finnur's recent change to
do extension-specific pageAction events, we could have continued
dispatching all pageActions events through
chrome.pageActions.onExecute if I would have thought to bring it up
during review.

As a counter-example, it would have been difficult to be backward
compat when we implemented signing, so we specifically decided to bite
the bullet and break everyone.

At 1.0, we'll make a big sweep through and actually remove all these old APIs.

- a

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to