Rust Update Policy for Firefox: Difference between revisions

Jump to navigation Jump to search

Rust Update Policy for Firefox (view source)

Revision as of 23:11, 18 October 2017

311 bytes removed ,  18 October 2017
Mark proposed schedule as adopted and improve layout
(→‎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
Rillian
Confirmed users
111

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1182505"

Navigation menu