|
|
| (22 intermediate revisions by 4 users 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 !! 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 6
| |
| |-
| |
| | Firefox 60 || Rust 1.23.0 || 2015 February 15 || 2018 May 1
| |
| |-
| |
| | Firefox 61 || Rust 1.25.0 || 2018 March 29 || 2018 June 26
| |
| |}
| |
| | |
| '''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 23
| |
| |-
| |
| | Rust 1.24.0 || 2018 March 6
| |
| |-
| |
| | Rust 1.25.0 || 2018 April 12
| |
| |-
| |
| | Rust 1.26.0 || 2018 May 24
| |
| |-
| |
| | Rust 1.27.0 || 2018 July 5
| |
| |}
| |
| | |
| == 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.
| |