Do we have a policy on CI coverage for vendored rust libraries? I'm concerned for example that we depend on a number of third-party rust libraries that don't do CI builds against rust stable and so it's possible they might break. I discovered that webrender CI for example is currently only building against 1.17.0 and nightly. I don't think we've actually encountered breakage from this but just wondering.
in third_party/rust$ find . -name ".travis.yml" | xargs grep -l "rust:" | xargs grep -L -- "stable" ./cfg-if/.travis.yml ./dtoa/.travis.yml ./itoa/.travis.yml ./mime/.travis.yml ./num/.travis.yml ./ordered-float/.travis.yml ./semver-0.1.20/.travis.yml ./synstructure/.travis.yml ./thread-id/.travis.yml ./unicode-width/.travis.yml ./unicode-xid/.travis.yml ./uuid/.travis.yml Cheers, kats On Tue, Aug 1, 2017 at 2:58 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > This is great - thanks Ralph! > > On Tue, Aug 1, 2017 at 11:53 AM, Ralph Giles <gi...@mozilla.com> wrote: > >> We've formalized a new plan for when we update the minimum-required Rust >> version for building Firefox. Starting later this week we'll require the >> latest stable Rust two weeks after it is released. >> >> This means we'll start requiring Rust 1.19.0 August 3rd. If you compile >> mozilla-central and haven't run './mach bootstrap' recently, I suggest >> doing so now to update. >> >> I've posted a full schedule >> <https://wiki.mozilla.org/Oxidation#Supported_Rust_versions_for_Firefox_builds> >> of when the minimum version will change for m-c, and what version of Rust >> will be required to build each Firefox release. These are expectations to >> aid in planning; we may delay particular bumps if there are issues or a >> code freeze, but the expectation is that we'll need to update our >> development environments by those dates. >> >> We expect ESR releases will stay on the Rust version of the corresponding >> stable release. >> >> This change is based on several meetings and discussions with contributors >> over the last two months. Rust is evolving quickly, and those working on >> Rust code need to know what release to target. Previously we updated the >> target version every few releases, whenever someone argued there was a >> sufficiently compelling feature. Negotiating that every time was >> distracting. Having a planned schedule lets everyone coordinate their work. >> Updating Rust regularly helps us iterate and improve the language, >> participating in the incredible momentum of the Rust developer community. >> >> Waiting two weeks gives contributors some time to update their >> environments. This is especially relevant to those who don't always have a >> fast network connection, or work on tier-3 targets where using upstream >> Rust packages isn't possible. >> >> This doesn't affect our policy for official Firefox builds, just developer >> builds and downstream packagers. I've written up details of the policy >> <https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox>, along with >> motivation and considered alternatives. Please read that before responding >> if you have concerns. I'll update the page next week in response to any >> persuasive arguments and move the minimum-version proposal to the current >> policy section. >> >> Thanks for you time, and let me know if you have any questions. >> >> Ralph Giles >> >> _______________________________________________ >> dev-builds mailing list >> dev-bui...@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-builds >> >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
