Don't do (c) -- its pointless. You won't be helping us test nightly changes and will miss any important fixes (especially security ones). Go ahead and switch to beta if you have to. Your extensions will work, you'll be helping us ship a good 56, and you'll get security fixes. Hate to lose nightly testers, but its to be expected with all the churn in this particular cycle.
-Dan Veditz On Aug 13, 2017 9:43 AM, "Ed Morley" <emor...@mozilla.com> wrote: > Some context: > - As part of Firefox 57 no longer supporting legacy (non web extension) > add-ons, the `extensions.legacy.enabled` preference was flipped to false in > the Aug 11th Nightly build [1]. > - Several backwards incompatible changes have already been made to Nightly > that can break legacy extensions [2]. > - The reasoning for the above being that it was desirable to spend as much > of the cycle as possible testing what we're actually going to ship to > end-users in the final 57 release. > - The authors of even some of the most popular extensions have said they > are targeting their finished web extensions at either Firefox 57's release > (>2017-11-14) or when it's in beta (>2017-09-20), rather than now. > > For the short term, Nightly users therefore have the following options: > a) Use latest nightly with legacy extensions disabled, and make do without > their extensions. > b) Flip the preference back so the legacy extensions are still loaded. > (However several extensions have already stopped working due to the > non-backwards compatible API changes.) > c) Disable Nightly updates and remain on a Nightly build prior to the > 2017-08-11 release. > d) Switch to the beta/release channel. (Some extension authors have been > recommending their users do this sadly) > > I've been using the Nightly channel for something like 8 years and normally > have no issue with the regressions that are expected on that channel - but > even for me, option (a) above is a complete non-starter [3]. I'm first > going to try (b), however one of my extensions is already broken (password > manager) only a few days in, and so it's likely that I'll end up having to > fall back to (c). > > I'm concerned that there may be many other Nightly users out there who > similarly pick (c)/(d) and thereby reduce our Nightly coverage temporarily, > just as we need it most. > > Questions: > > 1) Were there any estimates about how many Nightly users we think might > either disable updates or switch to the beta channel as a result of the > above? (Especially given recent efforts to try and build up Nightly ADUs, > which may end up being undone) > > 2) Whilst we have ADUs for Nightly as a whole, are we actively tracking how > many people are running the latest build, so can tell how many people do > (c)? > > 3) Whilst "testing what we're going to ship in release" and/or giving > extension authors a final "yes we're really doing this in 57" nudge to work > on their web extensions is important, where do we see the tipping point > between that and the loss of coverage from reduced Nightly coverage? Should > we hold off making any more of the backwards-incompatible API changes until > later in the 57 cycle? > > 4) Even for extensions that already have WIP web extension variants (eg > Adblock [4]), the add-ons manager doesn't automatically upgrade or suggest > a link to them currently. This seems like a quick win to both retain > Nightly users and increase testing of the web extension APIs (and something > we should have done before the breaking API changes IMO). Can we add extra > resources for driving this? > > Many thanks, > > Ed > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1388946 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1347507 > [3] For me NoScript and Adblock are essential for securely browsing; the > former doesn't yet have a full web extension variant. > [4] https://downloads.adblockplus.org/devbuilds/adblockplusfirefox/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
