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

[Jo Brown]

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.

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"
>