|
|
| (28 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]] |
| Rust toolchain dependency changes have been made on an ad-hoc basis. We
| |
| want to clarify the decision making and planning around this. We are
| |
| therefore defining a policy for 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.
| |
| | |
| 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.
| |
| | |
| 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.
| |
| | |
| 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.
| |
| | |
| == Current policy ==
| |
| | |
| === Official builds ===
| |
| | |
| ''We ship official stable Firefox with stable Rust.''
| |
| | |
| So far we've had no problem meeting this requirement. 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.
| |
| | |
| We do not currently follow a strict policy for when to increase the
| |
| minimum Rust version required by a specific Firefox version. In the
| |
| absence of a policy, we have incremented the minimum Rust version
| |
| whenever someone wanted to use a new feature, or a library required it.
| |
| So far, it hasn’t been necessary to require developers use unstable
| |
| Rust.
| |
| | |
| ==== The need to clarify our developer policy ====
| |
| | |
| For contributors, we also 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 is merged into Firefox this
| |
| has become more expensive.
| |
| | |
| Historically we've bumped this minimum every 3-4 Rust releases, which
| |
| 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 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.
| |
| | |
| The lack of a clear update policy creates unnecessary tension between
| |
| upstream Servo developers, Firefox developers and downstream community.
| |
| | |
| == Proposed policy update ==
| |
| | |
| ''We require a new stable Rust starting 2 weeks after it is released.''
| |
| | |
| This proposal 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 will 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.
| |
| | |
| My experience is that it takes about a week for version bumps to start
| |
| pulling in dependent crates using new language features, so this will
| |
| act as only a moderate restraint on Servo developers working on Gecko
| |
| modules. I think this is the correct trade-off between those two groups.
| |
| | |
| '''Release Firefox requirements under this proposal:'''
| |
| | |
| {| 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.20.0 || 2017 August 31 || 2017 November 14
| |
| |-
| |
| | Firefox 58 || Rust 1.21.0 || 2017 October 12 ||2018 January 16
| |
| |-
| |
| | Firefox 59 || Rust 1.22.0 || 2017 November 23 || 2018 March 6
| |
| |-
| |
| | Firefox 60 || Rust 1.23.0 || 2018 Feb 15 || 2018 May 1
| |
| |-
| |
| | Firefox 61 || Rust 1.25.0 || 2018 March 29 || 2018 June 26
| |
| |}
| |
| | |
| '''New feature adoption schedule under this proposal:'''
| |
| | |
| {| class="wikitable"
| |
| |-
| |
| ! Mozilla-central can use !! Starting on (Rust release + 2 weeks)
| |
| |-
| |
| | Rust 1.19.0 || 2017 August 3
| |
| |-
| |
| | Rust 1.20.0 || 2017 September 14
| |
| |-
| |
| | Rust 1.21.0 || 2017 October 26
| |
| |-
| |
| | Rust 1.22.0 || 2017 December 7
| |
| |-
| |
| | Rust 1.23.0 || 2018 January 18
| |
| |-
| |
| | 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
| |
| |}
| |
| | |
| == 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 to me, 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.
| |