Keeping add-ons compatible in the rapid release process
Jorge Villalobos
For those of you who don't know me, my name is Jorge and I'm the Add-ons
Developer Relations Lead. I'm the person you want to contact to discuss
any technical issues related to add-ons. I'm partly in charge of add-on
developer outreach, documentation, the review process for AMO, and
add-on compatibility.
Now that we're releasing major versions more quickly than ever before,
we need to establish a process that can efficiently communicate breaking
API changes to add-on developers, so that they have enough time to
prepare for new Firefox versions.
We have determined that the best time to identify and communicate these
changes is when a new version moves to the Aurora track. APIs should
remain frozen from that point on, with the exception of feature
backouts. We also know the kinds of changes that affect add-on
developers the most:
* Any change to any XPCOM interface. This includes interface removals
and merges. Even if there is no IDL interface or a [noscript]
descriptor, this could affect add-ons that use binary XPCOM.
* Any changes in the UI of the main browser window and, to a lesser
extent, other windows.
* Any changes in the way that events, observers, or other global
notifications work.
* Changes in the JS language that introduces reserved words or other
syntax changes.
* Changes in the global objects that are available to JS scripts, be it
chrome, components or modules.
* Changes in the way scripts can be loaded or executed, and in the way
chrome communicates with content.
If you are working on any bugs that do this, I encourage you to do any
(or all) of the following:
* Use the new addon-compat keyword.
* CC me on the bug (:jorgev or jo...@mozilla.com).
* Contact me directly.
It doesn't matter if you don't know when a bug will be fixed, or if
you're not sure it will impact add-on developers. I want to keep track
of all of these bugs as early as possible so I can determine their
impact on existing add-ons, and I can figure out if it requires
validation for the compatibility bump or even backing out (as it has
happened twice before with bug 672063 and bug 675075).
Knowing the impact of a bug fix early in the game helps add-on
developers prepare for upcoming releases, and it helps support the idea
that it's possible to maintain a rapid release process without
constantly breaking add-ons.
Thanks,
- Jorge
Joshua Cranmer
> * Any change to any XPCOM interface. This includes interface removals
> and merges. Even if there is no IDL interface or a [noscript]
> descriptor, this could affect add-ons that use binary XPCOM.
>
> * Any changes in the UI of the main browser window and, to a lesser
> extent, other windows.
>
> it chrome, components or modules.
At least these three options I suspect are possible to be verified by
running a static analysis script that can determine the differences
between versions... Have we thought about doing such a thing?
Paolo Amadini
> If you are working on any bugs that do this, I encourage you to do any
> (or all) of the following:
>
> * Use the new addon-compat keyword.
> * CC me on the bug (:jorgev or jo...@mozilla.com).
> * Contact me directly.
I guess we should also retroactively do this for bugs that already
landed in the Beta and Aurora channels, but no need to mark bugs that
reached release at present, right?
Paolo
Jorge Villalobos
We have discussed creating such tools, but very little has come out of
it. Mossop had worked on a tool that diffed IDLs between different
versions, but I think it needs some work. David Baron also suggested an
HG command to diff IDLs which should work as a temporary solution.
It'd be great to have a more robust tool in place, though.
- Jorge
Jorge Villalobos
I don't think that's necessary. It could be useful for historical
reasons, but the automatic validation and bump already ran for Firefox 8
(current Aurora) and unless a big compat problem arises, we won't run it
again.
- Jorge
Sheppy
> Knowing the impact of a bug fix early in the game helps add-on
> developers prepare for upcoming releases, and it helps support the idea
> that it's possible to maintain a rapid release process without
> constantly breaking add-ons.
With few, if any, exceptions, any bug that gets addon-compat should
get dev-doc-needed as well, to ensure that MDN documentation content
gets updated for the change.
Eric Shepherd
Developer Documentation Lead
Mozilla
http://www.bitstampede.com/
David E. Ross
> Hello all,
>
> For those of you who don't know me, my name is Jorge and I'm the Add-ons
> Developer Relations Lead. I'm the person you want to contact to discuss
> any technical issues related to add-ons. I'm partly in charge of add-on
> developer outreach, documentation, the review process for AMO, and
> add-on compatibility.
>
> Now that we're releasing major versions more quickly than ever before,
> we need to establish a process that can efficiently communicate breaking
> API changes to add-on developers, so that they have enough time to
> prepare for new Firefox versions.
>
> We have determined that the best time to identify and communicate these
> changes is when a new version moves to the Aurora track. APIs should
> remain frozen from that point on, with the exception of feature
> backouts. We also know the kinds of changes that affect add-on
> developers the most:
>
How about:
* Any change to preference variables, including new variables, the
obsolescence of existing variables, and changes to the meaning of
existing variables.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Steve Wendt
> For those of you who don't know me, my name is Jorge and I'm the Add-ons
> Developer Relations Lead. I'm the person you want to contact to discuss
> any technical issues related to add-ons. I'm partly in charge of add-on
> developer outreach, documentation, the review process for AMO, and
> add-on compatibility.
Does that include bugs in AMO? ;-)
https://bugzilla.mozilla.org/show_bug.cgi?id=610262
Jorge Villalobos
> On 8/30/11 10:11 AM, Jorge Villalobos wrote:
>> Hello all,
>>
>> For those of you who don't know me, my name is Jorge and I'm the Add-ons
>> Developer Relations Lead. I'm the person you want to contact to discuss
>> any technical issues related to add-ons. I'm partly in charge of add-on
>> developer outreach, documentation, the review process for AMO, and
>> add-on compatibility.
>>
>> Now that we're releasing major versions more quickly than ever before,
>> we need to establish a process that can efficiently communicate breaking
>> API changes to add-on developers, so that they have enough time to
>> prepare for new Firefox versions.
>>
>> We have determined that the best time to identify and communicate these
>> changes is when a new version moves to the Aurora track. APIs should
>> remain frozen from that point on, with the exception of feature
>> backouts. We also know the kinds of changes that affect add-on
>> developers the most:
>>
> [snipped]
>
> How about:
>
> * Any change to preference variables, including new variables, the
> obsolescence of existing variables, and changes to the meaning of
> existing variables.
>
Yes, good catch. New preferences shouldn't break add-ons, though. Only
changing the meaning of a pref (which should never happen), or the
removal or deprecation of existing preferences should be flagged for
addon-compat.
Thanks!
- Jorge
David E. Ross
Some extensions establish their own preference variables. It might be
possible that a new Gecko, Toolkit, or application variable serves the
same purpose. While such a new variable will clearly not break an
extension, it might allow the extension developer to eliminate a
redundant, extension-specific variable. Thus, the implementation of new
variable does need to be communicated.
David E. Ross
Bug #610262 was closed as a duplicate of bug #671085, another case of
closing an old bug in favor of a new one. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=671085>.
Christian Legnitto
This illustrates the difference between "dev-doc-needed" and "addon-compat" I think. We need/should document it but it wouldn't affect the add-on from working on the new version.
Thanks,
Christian
Arivald
Also, new preference may be connected to feature which was mandatory in
older version, and now become optional. So addon developer should make
sure addon will not break when feature is disabled. Especially if it is
disabled by default.
--
Arivald
Daniel Veditz
> Bug #610262 was closed as a duplicate of bug #671085, another case of
> closing an old bug in favor of a new one. See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=671085>.
Your point? It happens, deal with it. The same firehose effect that
causes dupes in the first place means bugs get missed or ignored.
When later re-found and filed as a dupe (dupes happen) by someone
with the ability to fix it or who manages to flag the right person
on IRC progress happens. Sad that the dupe was missed earlier, but
at this point is it really reasonable to copy the work in the newer
bug back to the nearly empty older bug simply to avoid "duping forward"?
A campaign to stomp out duping forward will be as successful as the
campaign to eliminate split infinitives. Nice windmill you've got
there, Quixote.
-Dan
Mark Banner
last few releases. Although none of it is scripted yet, I believe it
will cover most cases and is reasonably simple to run.
This takes just a couple of hours work (depending on the amount of
changes), and reduces the possible issues with missing bugs in the list.
The process is here:
https://wiki.mozilla.org/Thunderbird/Release_Driving/Rapid_Release_Activities/Compatibility_Bump
Comments and suggestions welcome.
Mark.