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.
> * 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.
> * Changes in the global objects that are available to JS scripts, be > 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?
> 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?
> On 8/30/2011 12:11 PM, Jorge Villalobos wrote: >> * 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.
>> * Changes in the global objects that are available to JS scripts, be >> 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?
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.
> On 30/08/2011 19.11, Jorge Villalobos wrote: >> 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
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.
On Aug 30, 1:11 pm, Jorge Villalobos <jo...@mozilla.com> wrote:
> 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.
> 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.
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.
> 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.
> 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.
> On 8/30/11 12:41 PM, David E. Ross wrote: >> 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
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.
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.
>> 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.
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.
> On 8/30/11 12:38 PM, Jorge Villalobos wrote: >> On 8/30/11 12:41 PM, David E. Ross wrote: >>> 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
> 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.
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.
> On 8/30/11 12:38 PM, Jorge Villalobos wrote: >> On 8/30/11 12:41 PM, David E. Ross wrote: >>> 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
> 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.
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.
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.
Discussion subject changed to "Process for finding changes relevant to add-ons for compatibility testing (was Re: Keeping add-ons compatible in the rapid release process)" by Mark Banner
> On 8/30/11 11:22 AM, Joshua Cranmer wrote:
>> On 8/30/2011 12:11 PM, Jorge Villalobos wrote:
>>> * 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.
>>> * Changes in the global objects that are available to JS scripts, be
>>> 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?
> 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.
I've now documented the process that Thunderbird has been using for the 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.
