[Mozilla Enterprise] Moving Firefox to a faster 4-week release cycle!

[Andrew C Aitchison]

On Mon, 23 Sep 2019, Jo Brown wrote:

> Security updates are point updates and are done EXACTLY the same time for ESR 
> as security updates for regular Fx.  There is no lag and that supposed lag is 
> NOT a reason to want to update faster.

Security FIXES in ESR are the same as in regular FF,
but new security FEATURES often appear in regular well before ESR.

Off-hand the only example I can give is that TLS1.3 support was enabled 
*by default* in FF61 so didn't make it into ESR before v69 (IIUC).
My recollection is that there have been better examples, where security 
features were not available to be turned on in ESR latest even though 
they were available in regular FF.


> As for how fast I want new features, I have finally left Fx ESR and regular 
> Fx after having started with Phoenix, then Firebird betas, then Fx 1.0 so 
> many years ago.  But I don't want new features except rarely and NO changes 
> in the GUI.  I LOVE Basilisk.  It has everything I could possibly want in a 
> great browser yet it is forked off of Fx 52 ESR. It is so outstanding that it 
> doesn't need updates except rarely (of course it gets regular security 
> updates) ...same with Fx 52 ESR which was the last great Fx.
>
> On 9/22/2019 8:56 PM, Andrew C Aitchison wrote:
>> 
>> Paul,
>> 
>> On the whole I agree with you.
>> 
>> However, when my OS was on ESR I found that I often wanted the new features
>> "under the hood", particularly the security features, much more quickly
>> than ESR releases made them available.
>> 
>> I do agree that quantum and the switch of plugin api was an unfortunate
>> "under the hood" change.
>> 
>> On Sun, 22 Sep 2019, Paul Kosinski via Enterprise wrote:
>> 
>>> I don't understand why a more rapid release cycle is good for *users*.
>>> Bugs, especially security bugs, obviously should be fixed quickly. But
>>> new features often tend to confuse users (many of whom can barely deal
>>> with existing features).
>>> 
>>> I am pretty expert in using -- and developing -- software (having done
>>> so since before Unix), but I prefer stability. I don't want changes in
>>> behavior or GUI appearance of software I normally use to take time away
>>> from whatever I'm working on, whether it's writing some C code, looking
>>> up specs, or just watching some video.
>>> 
>>> The "rapid release" of new features is OK *only* if they do not change
>>> the behavior, or GUI, of *existing* features. Even supposed stable ESR
>>> has been seriously disrupted by Quantum. Quantum has been disaster in
>>> this regard, as it has destroyed a tremendous number of important
>>> Add-Ons, many of which cannot be recreated with the new API.
>>> 
>>> So I am skeptical of the desirability of a more rapid release cycle. It
>>> might mainly be catering to users who view the browser as a game, rather
>>> than a means to accomplish actual work.
>>> 
>>> 
>>> On Fri, 20 Sep 2019 13:16:53 -0700
>>> Ritu Kothari <rkothari at mozilla.com> wrote:
>>>
>>>>  We?re excited to announce
>>>> <https://hacks.mozilla.org/2019/09/moving-firefox-to-a-faster-4-week-release-cycle/>
>>>> that we?re adjusting Firefox release cadence to increase our agility,
>>>> and to bring you new features more quickly. Starting Q1 2020, we plan
>>>> to ship a major Firefox release every 4 weeks.
>>>> 
>>>> Shorter release cycles provide greater flexibility to support product
>>>> planning and priority changes due to business or market requirements.
>>>> It allows us to be more agile and ship features faster while applying
>>>> the same rigor and due diligence needed to ship a high-quality and
>>>> stable release. *Major
>>>> updates to ESR* (Extended Support Release
>>>> <https://www.mozilla.org/en-US/firefox/enterprise/> for the
>>>> enterprise) *will remain yearly, as they do now*. There will be a 3
>>>> months support overlap between new ESR and end-of-life of previous
>>>> ESR version. The next two major ESR releases will be ~June 2020 and
>>>> ~June 2021. This change will be deployed gradually starting with
>>>> Fx71, achieving 4 week release cadence by Q1 2020. You can refer to
>>>> https://wiki.mozilla.org/Release_Management/Calendar for the latest
>>>> release dates and other  information.
>>>> 
>>>> As we slowly reduce our release cycle length, from 7 weeks down to 6,
>>>> 5, 4 weeks, there will be close monitoring of aspects like release
>>>> scope change; developer productivity impact (tree closure, build
>>>> failures); beta code churn (uplifts, new regressions); overall
>>>> release stabilization and quality (stability, performance, carryover
>>>> regressions). Our main goal is to identify bottlenecks that prevent
>>>> us from being more agile in our release cadence. Appropriate
>>>> mitigations will be put in place should our metrics highlight an
>>>> unexpected trend.
>>>> 
>>>> If you have any questions or concerns, please email
>>>> release-mgmt at mozilla.com
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Ritu Kothari
>>> _______________________________________________
>>> Enterprise mailing list
>>> Enterprise at mozilla.org
>>> https://mail.mozilla.org/listinfo/enterprise
>>> 
>>> To unsubscribe from this list, please visit 
>>> https://mail.mozilla.org/listinfo/enterprise or send an email to 
>>> enterprise-request at mozilla.org with a subject of "unsubscribe"
>>> 
>> _______________________________________________
>> Enterprise mailing list
>> Enterprise at mozilla.org
>> https://mail.mozilla.org/listinfo/enterprise
>> 
>> To unsubscribe from this list, please visit 
>> https://mail.mozilla.org/listinfo/enterprise or send an email to 
>> enterprise-request at mozilla.org with a subject of "unsubscribe"
>> 
> _______________________________________________
> Enterprise mailing list
> Enterprise at mozilla.org
> https://mail.mozilla.org/listinfo/enterprise
>
> To unsubscribe from this list, please visit 
> https://mail.mozilla.org/listinfo/enterprise or send an email to 
> enterprise-request at mozilla.org with a subject of "unsubscribe"
>