[Go Faster] Updating and installing new system add-ons

Lawrence Mandel lmandel at mozilla.com
Thu Sep 10 19:24:27 UTC 2015


Not serving updates to older versions seems like the expected approach to
me. Once we deprecate an OS - or more generally once we EOL a release, as
we do every 6 weeks - we no longer provide any support for that release. I
think being able to patch an old release is a nice to have but not a
requirement.

Lawrence

On Thu, Sep 10, 2015 at 3:20 PM, Benjamin Smedberg <bsmedberg at mozilla.com>
wrote:

> Would we continue to test those configurations? It seems unlikely that the
> addons would continue to work for long periods of time unless the API
> surface is extraordinarily stable and robust.
>
> I don't think we should continue shipping things if we're not going to
> test those configurations somehow.
>
> --BDS
>
> On Thu, Sep 10, 2015 at 3:06 PM, Ben Hearsum <bhearsum at mozilla.com> wrote:
>
>> I was talking with Chris AtLee about our plan for System Addon updates in
>> Balrog today, specifically around the idea of being able to stop serving
>> the updates every 6 weeks (eg, if we update Hello between 42 and 43, we can
>> stop serving it in Balrog when 43 ships because it will contain the latest
>> version). He pointed out that if we deprecate an OS, and stop serving
>> system addon updates when we ship the next version, those users will never
>> be able to get the latest compatible version. Probably not the end of the
>> world, since those users are stuck on an old version of Firefox anyways,
>> but it's not ideal. We may want to consider continuing to ship the latest
>> available system addons for each version of Firefox (similar to what we do
>> for GMP right now).
>>
>> On Tue, Sep 08, 2015 at 09:12:43AM -0700, Dave Townsend wrote:
>> > After discussions with Ben I've updated the section of the client plan
>> on
>> > how we update system add-ons:
>> >
>> https://wiki.mozilla.org/Firefox/Go_Faster/Client_Implementation_Plan#Discovering_system_add-ons
>> >
>> > It shows the actual server response we will be reading and is
>> essentially
>> > the same update mechanism that GMP uses.
>>
>> > _______________________________________________
>> > Gofaster mailing list
>> > Gofaster at mozilla.org
>> > https://mail.mozilla.org/listinfo/gofaster
>>
>>
>> _______________________________________________
>> Gofaster mailing list
>> Gofaster at mozilla.org
>> https://mail.mozilla.org/listinfo/gofaster
>>
>>
>
>
> --
> Benjamin Smedberg
> Engineering Manager, Firefox
>
>
> _______________________________________________
> Gofaster mailing list
> Gofaster at mozilla.org
> https://mail.mozilla.org/listinfo/gofaster
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150910/f71224e3/attachment.html>


More information about the Gofaster mailing list