<div dir="ltr"><div>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.<br><br></div>Lawrence<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 3:51 PM, Dave Townsend <span dir="ltr"><<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><div class="h5"><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 12:33 PM, Ben Hearsum <span dir="ltr"><<a href="mailto:bhearsum@mozilla.com" target="_blank">bhearsum@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
1) Firefox 42 ships<br>
2) 3 weeks later, Hello 42.1 ships through Balrog<br>
3) 3 weeks later, Firefox 43 ships<br>
<br>
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?<br>
<div><div><br>
On Thu, Sep 10, 2015 at 03:24:27PM -0400, Lawrence Mandel wrote:<br>
> Not serving updates to older versions seems like the expected approach to<br>
> me. Once we deprecate an OS - or more generally once we EOL a release, as<br>
> we do every 6 weeks - we no longer provide any support for that release. I<br>
> think being able to patch an old release is a nice to have but not a<br>
> requirement.<br>
><br>
> Lawrence<br>
><br>
> On Thu, Sep 10, 2015 at 3:20 PM, Benjamin Smedberg <<a href="mailto:bsmedberg@mozilla.com" target="_blank">bsmedberg@mozilla.com</a>><br>
> wrote:<br>
><br>
> > Would we continue to test those configurations? It seems unlikely that the<br>
> > addons would continue to work for long periods of time unless the API<br>
> > surface is extraordinarily stable and robust.<br>
> ><br>
> > I don't think we should continue shipping things if we're not going to<br>
> > test those configurations somehow.<br>
> ><br>
> > --BDS<br>
> ><br>
> > On Thu, Sep 10, 2015 at 3:06 PM, Ben Hearsum <<a href="mailto:bhearsum@mozilla.com" target="_blank">bhearsum@mozilla.com</a>> wrote:<br>
> ><br>
> >> I was talking with Chris AtLee about our plan for System Addon updates in<br>
> >> Balrog today, specifically around the idea of being able to stop serving<br>
> >> the updates every 6 weeks (eg, if we update Hello between 42 and 43, we can<br>
> >> stop serving it in Balrog when 43 ships because it will contain the latest<br>
> >> version). He pointed out that if we deprecate an OS, and stop serving<br>
> >> system addon updates when we ship the next version, those users will never<br>
> >> be able to get the latest compatible version. Probably not the end of the<br>
> >> world, since those users are stuck on an old version of Firefox anyways,<br>
> >> but it's not ideal. We may want to consider continuing to ship the latest<br>
> >> available system addons for each version of Firefox (similar to what we do<br>
> >> for GMP right now).<br>
> >><br>
> >> On Tue, Sep 08, 2015 at 09:12:43AM -0700, Dave Townsend wrote:<br>
> >> > After discussions with Ben I've updated the section of the client plan<br>
> >> on<br>
> >> > how we update system add-ons:<br>
> >> ><br>
> >> <a href="https://wiki.mozilla.org/Firefox/Go_Faster/Client_Implementation_Plan#Discovering_system_add-ons" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Firefox/Go_Faster/Client_Implementation_Plan#Discovering_system_add-ons</a><br>
> >> ><br>
> >> > It shows the actual server response we will be reading and is<br>
> >> essentially<br>
> >> > the same update mechanism that GMP uses.<br>
> >><br>
> >> > _______________________________________________<br>
> >> > Gofaster mailing list<br>
> >> > <a href="mailto:Gofaster@mozilla.org" target="_blank">Gofaster@mozilla.org</a><br>
> >> > <a href="https://mail.mozilla.org/listinfo/gofaster" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/gofaster</a><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> Gofaster mailing list<br>
> >> <a href="mailto:Gofaster@mozilla.org" target="_blank">Gofaster@mozilla.org</a><br>
> >> <a href="https://mail.mozilla.org/listinfo/gofaster" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/gofaster</a><br>
> >><br>
> >><br>
> ><br>
> ><br>
> > --<br>
> > Benjamin Smedberg<br>
> > Engineering Manager, Firefox<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Gofaster mailing list<br>
> > <a href="mailto:Gofaster@mozilla.org" target="_blank">Gofaster@mozilla.org</a><br>
> > <a href="https://mail.mozilla.org/listinfo/gofaster" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/gofaster</a><br>
> ><br>
> ><br>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>