Schedule for incrementing allowed AMO updates

Mark Banner mbanner at
Thu Jun 16 09:02:14 UTC 2011

On 08/06/2011 16:48, Kent James wrote:
> I believe that it should be possible for extension writers to maintain 
> their extensions such that extensions are declared compatible with a 
> new Thunderbird version BEFORE any automatic update occurs. Formerly, 
> at least in theory someone could delay an update until their critical 
> extensions were compatible. With automatic updates, that is not 
> possible, so an extension writer who is diligent should update their 
> extension compatibility before the automatic update occurs.
Even with automatic updates, I believe we won't be automatically 
updating a user if their extensions are incompatible. If you've seen 
something to the contrary, please let me know.
> For this to happen, then the allowed AMO compatibility needs to be 
> incremented from x.0a2 to x.0 with a reasonable delay before the beta 
> channel users will receive their core update. I would suggest that 
> this increment is done right after the code for a version is copied 
> into the aurora repository. Then extension writers would then have the 
> 6 week aurora window to fix their extension compatibility and get it 
> reviewed and updated before the automatic beta channel core update.
So here is the rough plan of what will be happening:

  * At the Aurora branch point the x.0a2 version will be added to AMO.
  * Builds will be produced within a few days.
  * Somewhere around this time (I'm not yet sure if it'd be in-between
    the branch point and builds being produced, or just after), the
    validator will be run against the add-ons on AMO and add-on max
    versions bumped to x.0a2 if no compatibility issues are seen.
  * Once aurora has been stabilised wrt features, add x.* version to AMO
    (this may actually happen earlier). At the same time, re-run the
    compatibility bump tool, and bump add-on max versions to x.*.

Hence this will get us compatibility for beta users before the merge to 
the beta channel and the first beta build.

We didn't get to do this for Miramar because the compatibility reporter 
had just been created and we haven't had time to get it hooked up for 
Thunderbird. We should be doing that for 6.0a2, but it may take us a 
week or so from now to get there.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the tb-planning mailing list