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

Lawrence Mandel lmandel at mozilla.com
Wed Sep 30 22:50:15 UTC 2015


Late response but I agree with our action depending on the circumstance. If
we decided to define a watershed moment (like dropping support for an OS),
we may choose to continue to serve the add-on point release update.
Officially our policy is that we EOL a release as soon as a new one is
available. That means no support. The fact that users are now stuck on the
release is a decision that we have made presumably to reduce our cost to
continue to support an old platform.

Lawrence

On Thu, Sep 10, 2015 at 3:51 PM, Dave Townsend <dtownsend at mozilla.com>
wrote:

> I think it's likely to depend on the circumstances, does Hello 42.1 fix a
> massive vulnerability and do we still have a lot of users running Firefox
> 42? That might be cause to keep it on the wire. Other cases maybe not. The
> way the client code works is flexible and we can choose to do either by
> either leaving the rules on the server or removing them.
>
>
> On Thu, Sep 10, 2015 at 12:33 PM, Ben Hearsum <bhearsum at mozilla.com>
> wrote:
>
>> Sorry, I think I wasn't quite clear here. I'm taking about continuing to
>> serve "point" releases of system addons. For example, consider the
>> following:
>> 1) Firefox 42 ships
>> 2) 3 weeks later, Hello 42.1 ships through Balrog
>> 3) 3 weeks later, Firefox 43 ships
>>
>> In our original plan, we would stop serving Hello 42.1 to Firefox 42
>> users through Balrog after Firefox 43 ships, because presumably those users
>> will install Firefox 43 instead. If we also deprecated an OS version in
>> Firefox 43, it means users on that OS version that didn't already get Hello
>> 42.1 would never get it (because Balrog isn't offering it anymore, and they
>> can't get Firefox 43). Does that make any more sense? Is it too much of an
>> edge case to care?
>>
>> On Thu, Sep 10, 2015 at 03:24:27PM -0400, Lawrence Mandel wrote:
>> > 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/20150930/9caadebb/attachment.html>


More information about the Gofaster mailing list