Difference between revisions of "Rust Update Policy for Firefox"

From MozillaWiki
Jump to: navigation, search
(Proposed policy update: Document Firefox 57 slipping to Rust 1.19.0)
(Mark proposed schedule as adopted and improve layout)
Line 31: Line 31:
 
community. We (as Gecko developers) should embrace it.
 
community. We (as Gecko developers) should embrace it.
  
== Current policy ==
+
== 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.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:'''
 +
 
 +
{| 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 (was 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
 +
|}
 +
 
 +
== Policy ==
  
 
=== Official builds ===
 
=== Official builds ===
Line 56: Line 102:
 
`rustup` for `mach bootstrap` tools, or try other variations.
 
`rustup` for `mach bootstrap` tools, or try other variations.
  
We do not currently follow a strict policy for when to increase the
+
=== Required versions ===
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.''
 
''We require a new stable Rust starting 2 weeks after it is released.''
  
This proposal effectively removes the difference between the required
+
This policy effectively removes the difference between the required
 
Rust version and the default target for official builds, while still
 
Rust version and the default target for official builds, while still
 
giving tier-3 developers some time to process toolchain updates.
 
giving tier-3 developers some time to process toolchain updates.
  
Downstream packagers will still have 2-3 months to package each stable
+
Downstream packagers still have 2-3 months to package each stable
 
Rust release before it’s required by a new Firefox release.
 
Rust release before it’s required by a new Firefox release.
  
Line 102: Line 121:
 
so backporting security fixes may require Rust compatibility work too.
 
so backporting security fixes may require Rust compatibility work too.
  
My experience is that it takes about a week for version bumps to start
+
=== Rationale ===
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:'''
+
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.
  
{| class="wikitable"
+
For contributors, we maintain a minimum supported Rust toolchain
|-
+
This helps those working on tier-3 platforms, where updating Rust can be
! Firefox Version !! Requires !! Rust release date !! Firefox release date
+
more difficult than just running `rustup update`, by giving them time to adapt.
|-
+
However, it means other contributors must backport newer work to
| Firefox 56 || Rust 1.17.0 || 2017 April 27 || 2017 September 26
+
maintain compatibility. As more Rust code was merged into Firefox this
|-
+
became expensive.
| Firefox 57 || Rust 1.19.0 || 2017 July 20 || 2017 November 14
+
 
|-
+
Historically we bumped this minimum every 3-4 Rust releases, which also
| Firefox 58 || Rust 1.21.0 || 2017 October 12 ||2018 January 16
+
helped contributors on slow network connections since they didn't have
|-
+
to download toolchains as often. Deciding to bump this way involved
| Firefox 59 || Rust 1.22.0 || 2017 November 23 || 2018 March 6
+
negotiating each change, which by late 2017 many contributors felt was a
|-
+
more significant burden. Delaying to give tier-3 platforms months instead of
| Firefox 60 || Rust 1.23.0 || 2018 Feb 15 || 2018 May 1
+
weeks to update their Rust packages is also not considered a good
|-
+
trade-off.
| Firefox 61 || Rust 1.25.0 || 2018 March 29 || 2018 June 26
 
|}
 
  
'''New feature adoption schedule under this proposal:'''
+
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.
  
{| 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 (was 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 ==
+
==== Alternate Proposals ====
  
 
''We require nightly Rust''
 
''We require nightly Rust''
Line 167: Line 166:
 
''We require beta Rust''
 
''We require beta Rust''
  
I don’t think anyone has suggested this to me, but I thought I’d include
+
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
 
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
 
at the expense of more churn for contributors. It’s not a good trade-off

Revision as of 23:11, 18 October 2017

Firefox depends on code written in the Rust programming language. 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.

Schedule

Release Firefox requirements:

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.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:

Mozilla-central can use Starting on (Rust release + 2 weeks)
Rust 1.19.0 2017 August 3
Rust 1.20.0 2017 October 17 (was 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

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.

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

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.