Rust Update Policy for Firefox: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(redirect)
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
Firefox [[Oxidation|depends on code]] written in the [https://www.rust-lang.org/ Rust programming language].
#redirect [[fsd:writing-rust-code/update-policy.html]]
 
We document here the decision making and planning around when we update the Rust toolchains used and required to build Firefox.
 
This allows contributors to know when new features will be usable, and
downstream packagers to know what toolchain will be required for each
Firefox release. Both benefit from the predictability of a schedule.
 
== Schedule ==
 
'''Release Firefox requirements:'''
 
{| class="wikitable"
|-
! Firefox Version !! Requires !! Rust release date !! Nightly Soft Freeze !! Firefox release date
|-
| Firefox 56 || Rust 1.17.0 || 2017 April 27 || || 2017 September 26
|-
| Firefox 57 || Rust 1.19.0 || 2017 July 20 || || 2017 November 14
|-
| Firefox 58 || Rust 1.21.0 || 2017 October 12 || || 2018 January 16
|-
| Firefox 59 || Rust 1.22.1 || 2017 November 23 || || 2018 March 13
|-
| Firefox 60 || Rust 1.24.0 || 2018 February 15 || || 2018 May 9
|-
| Firefox 61 || Rust 1.24.0 || 2018 February 15 || || 2018 June 26
|-
| Firefox 62 || Rust 1.24.0 || 2018 February 15 || || 2018 September 5
|-
| Firefox 63 || Rust 1.28.0 || 2018 August 2 || || 2018 October 23
|-
| Firefox 64 || Rust 1.29.0 || 2018 September 13 || 2018 October 15 || 2018 December 11
|-
| Firefox 65 || Rust 1.30.0 || 2018 October 25 || 2018 December 3 || 2019 January 29
|-
| Firefox 66 || Rust 1.31.0 || 2018 December 6 || 2019 January 21 || 2019 March 19
|-
| Firefox 67 || Rust 1.32.0 || 2019 January 17 || 2019 March 11 || 2019 May 21
|-
| Firefox 68 || Rust 1.34.0 || 2019 April 11 || 2019 May 13 || 2019 July 9
|-
| Firefox 69 || Rust 1.35.0 || 2019 May 23 || 2019 July 1 || 2019 September 3
|-
| Firefox 70 || Rust 1.36.0 || 2019 July 4 || 2019 August 26 || 2019 October 22
|-
| Firefox 71 || Rust 1.37.0 || 2019 August 15 || 2019 October 14 || 2019 December 3
|-
| Firefox 72 || Rust 1.37.0 || 2019 August 15 || 2019 November 25 || 2020 January 7
|-
| Firefox 73 || Rust 1.39.0 || 2019 November 7 || 2020 January 1 || 2020 February 11
|-
| Firefox 74 || Rust 1.39.0 || 2019 November 7 || 2020 February 6 || 2020 March 10
|-
| Firefox 75 || Rust 1.41.0 || 2020 January 30 || 2020 March 5 || 2020 April 7
|-
| Firefox 76 || Rust 1.41.0 || 2020 March 12 || 2020 April 2 || 2020 May 5
|-
! Estimated
|-
| Firefox 77 || Rust 1.43.0 || 2020 April 23 || 2020 April 30 || 2020 June 2
|-
| Firefox 78 || Rust 1.43.0 || 2020 April 23 || 2020 May 28 || 2020 June 30
|-
| Firefox 79 || Rust 1.44.0 || 2020 June 4 || 2020 June 26 || 2020 July 28
|-
| Firefox 80 || Rust 1.45.0 || 2020 July 16 || 2020 July 23 || 2020 August 25
|-
| Firefox 81 || Rust 1.45.0 || 2020 July 16 || 2020 August 20 || 2020 September 22
|}
 
'''New feature adoption schedule:'''
 
{| class="wikitable"
|-
! Mozilla-central can use !! Starting on (Rust release + 2 weeks)
|-
| Rust 1.19.0 || 2017 August 3
|-
| Rust 1.20.0 || 2017 October 17 ([https://bugzilla.mozilla.org/show_bug.cgi?id=1396884 was] September 14)
|-
| Rust 1.21.0 || 2017 October 26
|-
| Rust 1.22.0 || 2017 December 7
|-
| Rust 1.23.0 || 2018 January 26 ([https://bugzilla.mozilla.org/show_bug.cgi?id=1418081#c8 was] January 18)
|-
| Rust 1.24.0 || 2018 March 1
|-
| Rust 1.25.0 || 2018 April 12
|-
| Rust 1.26.0 || 2018 May 24
|-
| Rust 1.27.0 || 2018 July 5
|-
| Rust 1.28.0 || 2018 August 16
|-
| Rust 1.29.0 || 2018 September 27
|-
| Rust 1.30.0 || 2018 November 8
|}
 
== Policy ==
 
=== Official builds ===
 
''We ship official stable Firefox with stable Rust.''
 
Typically we build Firefox Nightly with the current stable Rust and let
that configuration ride through beta to release. There have been frequent
exceptions where we've adopted a beta Rust during the Nightly phase to
address some platform support issue, and later updated when that Rust
version became stable. For example, we needed to use beta Rust for our
own builds when we first added Rust support to Firefox for Android.
 
The policy provides good stability guarantees once Firefox is in
release, while giving us the freedom to respond to the issues experience
shows we'll need to address during development.
 
=== Developer builds ===
 
''Local developer builds use whatever Rust toolchain is available on the system.''
 
Someone building Firefox can maintain the latest stable Rust with the
`rustup` for `mach bootstrap` tools, or try other variations.
 
=== Required versions ===
 
''We require a new stable Rust starting 2 weeks after it is released.''
 
This policy effectively removes the difference between the required
Rust version and the default target for official builds, while still
giving tier-3 developers some time to process toolchain updates.
 
Downstream packagers still have 2-3 months to package each stable
Rust release before it’s required by a new Firefox release.
 
The stable+two weeks requirement is a rough target. We expect to hit
it within a few days for most Rust releases. But, for example, when the
target date falls within a mozilla-central soft freeze (before branching
for a beta release) we may update a week later.
 
We expect esr releases will stay on the same minimum Rust version,
so backporting security fixes may require Rust compatibility work too.
 
=== Rationale ===
 
We need to be fast and efficient across the whole system which includes
the Rust, Servo, and Firefox development teams. We realise that the
decisions we make have an impact downstream, and we want to minimise the
negative aspects of that impact. However, we cannot do so at the expense
of our own productivity.
 
There are many other stakeholders, of course, but our work in Gecko and
Servo are major drivers for Rust language, compiler, and library
development. That influence is more effective if we can iterate quickly.
Servo itself often uses experimental language features to give the
necessary early feedback on features as they evolve.
 
Rust updates every six weeks, just like Firefox. This is more like web
languages than native languages, but it's been great for building
community. We (as Gecko developers) should embrace it.
 
Many of us think of the toolchain and source code as being conceptually
different. At this point in time, Rust is evolving much more quickly
than Python or C++. For now it is easier to think of Rust as being part
of Firefox, rather than thinking of it like a C++ toolchain with decades
of history which we we have little influence on.
 
Official build configurations are generally part of the Firefox
code itself, subject to normal review, and don't affect anyone else.
Therefore it's straightforward to manage the Rust toolchain we use
directly like any other change.
 
For contributors, we maintain a minimum supported Rust toolchain
This helps those working on tier-3 platforms, where updating Rust can be
more difficult than just running `rustup update`, by giving them time to adapt.
However, it means other contributors must backport newer work to
maintain compatibility. As more Rust code was merged into Firefox this
became expensive.
 
Historically we bumped this minimum every 3-4 Rust releases, which also
helped contributors on slow network connections since they didn't have
to download toolchains as often. Deciding to bump this way involved
negotiating each change, which by late 2017 many contributors felt was a
more significant burden. Delaying to give tier-3 platforms months instead of
weeks to update their Rust packages is also not considered a good
trade-off.
 
My experience is that it takes about a week for version bumps to start
pulling in dependent crates using new language features, so updating
after a couple of weeks acts as only a moderate restraint on Servo
developers working on Gecko modules.
I think this is the correct trade-off between those two groups.
 
==== Alternate Proposals ====
 
''We require nightly Rust''
 
This would certainly speed up the feedback with language design.
However, we would frequently encounter build breakage when unstable
language features change. Even Servo pins to a specific nightly to avoid
this problem. That’s appropriate for a smaller research project, but not
something the size of Firefox.
 
We should and do test building Firefox with nightly Rust to catch
compiler issues, but that’s different from requiring everyone to use
unstable Rust.
 
''We require beta Rust''
 
I don’t think anyone has suggested this, but I thought I’d include
it for completeness. This shortens the feedback cycle for new features
at the expense of more churn for contributors. It’s not a good trade-off
because by the time a new feature is stabilized in beta Rust, it’s too
late to change it much. This is better served by particular developers
working with upstream directly. I believe beta is also something of an
“excluded middle” in the Rust ecosystem, with most contributors working
with either stable or unstable nightly Rust.
 
''We require the previous stable Rust once a new stable Rust is released.''
 
That is, we bump the Firefox minimum to Rust 1.n.m when rust 1.(n+1).0
stable is released. This is roughly every 6 weeks, with six weeks to
update before bumping into the new requirement.  This policy might be
simpler for contributors to remember. There's not much difference in the
amount of time downstream packager receive for a particular Firefox
release. This is a trade-off of more time for tier-3 developers against
people working on Gecko/Servo components doing extra work to maintain
compatibility. As I say above, I think this is the wrong choice.
 
''We bump the minimum Rust version only when new features are compelling.''
 
This reduces churn for developers, but the need to negotiate each bump
takes time better spent on development. See the motivation section
above.

Latest revision as of 09:02, 13 April 2022

Redirect to:

Retrieved from "https://wiki.allizom.org/index.php?title=Rust_Update_Policy_for_Firefox&oldid=1241861"