Add-on compatibility & rapid releases proposal
Justin Scott
We've been working on a new plan for add-on compatibility to support
releases every 6 weeks, which wouldn't be possible with our previous
compatibility cycles of 3 months.
With this plan, users of Aurora, Beta, and Release channels will
automatically have add-on compatibility updated until we detect that an
add-on has been broken. This is changing the compatibility process to
default to compatible instead of incompatible for AMO-hosted add-ons.
There are 3 major pieces:
1. Firefox and platform developers should take add-on compatibility into
account with any changes they make. Among the criteria for changes
making it through to aurora and beta channels will be the impact on
add-on compatibility. Especially for early versions (Firefox 5, 6) when
the Add-on SDK is not yet stable, we should be cautious about breaking
changes.
2. Before developers land changes that will break add-on compatibility,
they should follow a compatibility notification process of posting to a
newsgroup (mozilla.dev.compatibility?) with a description of the change,
the reasons for the change, and patterns we can look for in add-ons to
identify those affected. Documentation will be updated and blog posts
will be made, and the patterns will be added to AMO's validator.
3. The day before we branch for Aurora, the AMO validator will be run on
the latest versions of all add-ons and any that are flagged from the
compatibility patterns or that use binary components will be emailed to
inform them they'll need to manually update compatibility. All other
add-ons that are compatible with the previous release will automatically
be bumped to the final version.
As an example, if we were currently following this process, yesterday we
would have bumped all 4.0.* compatible add-ons to 5.*
Users of nightly builds will still need to disable compatibility
checking if they wish to use add-ons.
If changes or features are backed out once they're on Aurora, we'll need
to run the validator again to handle that case.
Add-ons that aren't hosted on AMO can use their own updateURL mechanism
to bump compatibility without issuing an actual update, just as AMO
does. They'll also be able to use our standalone validator
(https://addons.mozilla.org/en-US/developers/addon/validate) to run
compatibility tests without being hosted on AMO.
----
That's the minimum required for automatic compatibility, but we also
want to improve our tools to make the process even smoother:
* We'll monitor compatibility report submissions and an increase in
reports of broken compatibility will flag the add-on to not be
automatically bumped (or if the reports are on Aurora, to be bumped back
down). This will help catch UI changes and harder-to-detect problems.
* We'll integrate Mossop's interface diff tool with our validator to
flag changed interfaces that add-ons use to highlight changes that may
not have been fully flagged.
Please let me know what you think of the proposal. It's not going to be
in effect in time for Firefox 5's Aurora but I'm hopeful we can start it
in a few weeks.
Thanks,
Justin
Cameron McCormack
> 1. Firefox and platform developers should take add-on compatibility
> into account with any changes they make.
Is there a write-up somewhere that lists the kinds of changes can break
add-on compatibility?
--
Cameron McCormack ≝ http://mcc.id.au/
Robert Kaiser
> As an example, if we were currently following this process, yesterday we
> would have bumped all 4.0.* compatible add-ons to 5.*
Well, that's a big "if" as right now, we don't even have 5.0a2 and 6.0a1
available on AMO, even though tinderbox builds with those versions exist
already and nightly/"morningly"/"daily" (whatever you call them) builds
are about to surface with those versions.
This brings me to the actual question:
How are we dealing with Firefox 5 and 6, which are both already in
various stages of development, with some things already landed on them?
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
beltzner
Any interface change.
Any interface or XUL removal.
I think in addition to these steps we need to really be pushing people
towards and building up the power of the Add On SDK, and perhaps calling out
"stable" or "protected" interfaces and XUL IDs that we recommend people use
in preference to others.
cheers,
mike
On 13/04/2011 9:47 AM, "Cameron McCormack" <c...@mcc.id.au> wrote:
Robert Strong
rely on our string names as well.
Robert
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Christian Legnitto
On Apr 12, 2011, at 6:59 PM, Robert Kaiser wrote:
> Justin Scott schrieb:
>> As an example, if we were currently following this process, yesterday we
>> would have bumped all 4.0.* compatible add-ons to 5.*
>
> Well, that's a big "if" as right now, we don't even have 5.0a2 and 6.0a1 available on AMO, even though tinderbox builds with those versions exist already and nightly/"morningly"/"daily" (whatever you call them) builds are about to surface with those versions.
My bad, I was supposed to do this during the merge. These versions are up there (but might still need to be manually added to the compatibility reporter. I gave fligtar heads up before the version change but not sure what happened yet.
I think we'll want to let people specify down to *a1 and *a2, as interfaces may change between those (backouts / pref offs mainly)
Christian
Robert Kaiser
>
> On Apr 12, 2011, at 6:59 PM, Robert Kaiser wrote:
>
>> Justin Scott schrieb:
>>> As an example, if we were currently following this process, yesterday we
>>> would have bumped all 4.0.* compatible add-ons to 5.*
>>
>> Well, that's a big "if" as right now, we don't even have 5.0a2 and 6.0a1 available on AMO, even though tinderbox builds with those versions exist already and nightly/"morningly"/"daily" (whatever you call them) builds are about to surface with those versions.
>
> My bad, I was supposed to do this during the merge. These versions are up there (but might still need to be manually added to the compatibility reporter. I gave fligtar heads up before the version change but not sure what happened yet.
Ah, cool, thanks!
> I think we'll want to let people specify down to *a1 and *a2, as interfaces may change between those (backouts / pref offs mainly)
I agree.
David Ascher
string and interface changes we're talking about? Seems it might be
worth doing some tooling and automation rather than expecting dozens
and dozens of people to be perfect.
--da
Jesse Ruderman
Seems to me this creates more work for nightly users and adds risk for
Aurora users. Can you explain your reasoning here?
Henri Sivonen
> Any interface change.
I think this a bit too generalized as a policy.
There are interfaces whose name starts with "nsI" and that have an
interface ID for QI but that are very much internal interfaces in the
sense that any extension trying to use the interface would be in serious
trouble due to very tight coupling of the interface with implementation
details to the point of the interface not making sense in any other
context than as part of some complex Gecko-internal choreography.
As an example, I'm most familiar with nsIParser. It would be foolish for
any extension to try to use it in any way, because it's so tightly
coupled with the document load choreography as a whole. Yet, to adhere
to the interface freeze rules, I had to treat the interface frozen late
in the Firefox 4 cycle, which lead to increment of code ugliness without
a real benefit.
Eventually, it would be great to deCOMtaminate "interfaces" of this
nature, but as long as we aren't there, I'd like to propose not treating
nsI* interfaces that aren't [scriptable] as frozen during aurora or
maybe not even during beta. After all, the new world requires binary
extensions to be recompiled anyway, so there doesn't seem to be much of
a win from allowing binary extension developers to compile at the start
of a release train and to avoid recompiling near the stable release.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Gervase Markham
> 2. Before developers land changes that will break add-on compatibility,
> they should follow a compatibility notification process of posting to a
> newsgroup (mozilla.dev.compatibility?) with a description of the change,
mozilla.addons.compatibility, I suggest. If you want this, no problem -
file a bug.
Gerv
alex_mayorga
please?
https://bugzilla.mozilla.org/show_bug.cgi?id=649640
Thanks in advance,
Alex Mayorga Adame
Johnathan Nightingale
> Eventually, it would be great to deCOMtaminate "interfaces" of this
> nature, but as long as we aren't there, I'd like to propose not treating
> nsI* interfaces that aren't [scriptable] as frozen during aurora or
> maybe not even during beta. After all, the new world requires binary
> extensions to be recompiled anyway, so there doesn't seem to be much of
> a win from allowing binary extension developers to compile at the start
> of a release train and to avoid recompiling near the stable release.
Calling out Henri's proposal so it doesn't get lost in the rest of his reply. I think he's proposing:
mozilla-central: unfrozen (but see fligtar's pieces around notification for API bustage)
mozilla-aurora: [scriptable] interfaces frozen
mozilla-beta: all interfaces frozen
I'm toughening up Henri's language around beta but not, I think, unfairly.
Devs: is this rule likely to unacceptably fetter you?
Fligtar/AMO: is this rule in keeping with the spirit of your proposal?
This still complicates life for binary components who link against non-scriptable interfaces and have long QA lead times (a distressingly non-empty set), but we can't move as slowly as they'd like us to, regardless.
J
---
Johnathan Nightingale
Director of Firefox Engineering
joh...@mozilla.com
beltzner
> Fligtar/AMO: is this rule in keeping with the spirit of your proposal?
I think the proposal is good, yes, in terms of how to ensure that we allow
iterative freedom on trunk and give a heads up to downstream users about
upcoming changes.
Unless we carve out a set of "safe, less likely to change" and "unsafe,
always likely to change" interfaces though, I suspect we'll be reducing the
area of risk but retaining the key problem of annoying add on developers and
users of complex add-ons or software that calls into Firefox.
cheers,
mike
Benjamin Smedberg
>
> any extension to try to use it in any way, because it's so tightly
> coupled with the document load choreography as a whole. Yet, to adhere
> to the interface freeze rules, I had to treat the interface frozen late
> in the Firefox 4 cycle, which lead to increment of code ugliness without
> a real benefit.
Those binary extensions that do exist need to begin their development
cycle at aurora, not beta... 12 weeks is already pretty short for some
of them, and 6 weeks is basically impossible.
The only exception to this rule should be, I think, backouts for
regressions which changed interfaces, where we change back to the
original version. And even this needs to have some pretty serious messaging.
--BDS
Justin Scott
> How are we dealing with Firefox 5 and 6, which are both already in
> various stages of development, with some things already landed on them?
We're working on gathering a list of the changes in Firefox 5
(https://bugzilla.mozilla.org/show_bug.cgi?id=648664) and will scan the
add-ons for those changes and then do the compatibility bump. It's going
to be several weeks into the process as opposed to before the Aurora
branching, but that's just because it's the first time.
Until that happens, compatibility will be like it used to where users
will have to disable checking or install the Add-on Compatibility
Reporter in order to use add-ons on Aurora.
Robert O'Callahan
> Eventually, it would be great to deCOMtaminate "interfaces" of this
> nature, but as long as we aren't there
>
This is in fact a strong incentive to deCOMtaminate various interfaces :-).
Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Justin Scott
Changes will be landing constantly in nightly builds, some of which will
be backed out and then back in, and I don't feel comfortable claiming
that add-ons will be automatically compatible with all of the changes
that will happen to nightlies over 6 weeks.
Nightly testers are already familiar with the process of disabling
compatibility checking if they want to use add-ons, and it's not
feasible for us to look after the compatibility of all add-ons on a
daily basis.
Robert Kaiser
Ah, OK. Makes sense.
Philip Chee
I suggest cross posting to mozilla.dev.extensions but most extension
authors don't read that either. Those that try to keep on top of things
probably hang out more often in forums.addons.mozilla or
forums.mozillazine.org.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Justin Scott
necessary to support this plan. I've also posted this to our blog with a
flowchart of what this looks like:
http://blog.mozilla.com/addons/2011/04/19/add-on-compatibility-rapid-releases/
I'm sure this will catch the eyes of many more add-on developers and
we'll get additional feedback.
I'll be away until next Tuesday, April 26th, and will respond to any
additional feedback then.
Thanks!
Justin
patrickjdempsey
Will this be the same as the current Validation scanner? If so, the
Validation scanner needs some work, specifically for Themes. It
currently flags a Warning for Localization for Themes even though
Themes are not localized, and it also flags Security Warnings for
"modification of the Identity Box" which is weird because Themes
*have* to "modify" the Identity Box in order to theme them. ;) If
these "false negatives" count, then no Themes would automatically
update, am I correct?
Secondly, in addition to XUL or interface changes, one of the big
things that breaks themes is changing of CSS selectors and
properties. Between Firefox 3.5 and 3.6 there were several of these
like the switch from [chromedir="rtl"] to :-moz-locale-dir(rtl) and
from [empty="true"] to [isempty="true"], which in 4.0 changed to :-moz-
placeholder! Property changes are less dramatic because there tends
to be a backwards compatibility carry over from one version to the
next, but it's hard to know when these are EOL'd until they show up in
the Error panel. An example of this is -moz-border-radius changing to
border-radius, where-in Themes need to continue to use -moz-border-
radius in order to support Firefox 3.6.
-patrickjdempsey