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 <[email protected]> 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
[email protected]
Thanks,
Ritu Kothari
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit
https://mail.mozilla.org/listinfo/enterprise or send an email to
[email protected] with a subject of "unsubscribe"
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit
https://mail.mozilla.org/listinfo/enterprise or send an email to
[email protected] with a subject of "unsubscribe"
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit
https://mail.mozilla.org/listinfo/enterprise or send an email to
[email protected] with a subject of "unsubscribe"
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise
or send an email to [email protected] with a subject of
"unsubscribe"
