PSA: 1.0.0-beta.2 is out

[brson]

We’ve pushed the first incremental update to the 1.0 beta of this cycle, 1.0.0-beta.2, which can be downloaded from the website.

Part of the beta process involves testing, identifying regressions and applying bugfixes, and as such we will release updates to the beta as needed, with an expected frequency of roughly once per week. This push includes a merge from the nightly branch, bringing 1.0 completely up to date with nightly. For the rest of this development cycle we currently intend to only cherry-pick further fixes, which is the model that will be taken for updating the beta branch from here out.

We have no changelog for this update, but the final stable release will include a complete changelog for the 1.0 cycle.

I expect that these incremental updates to betas will not be highly-publicized in the future as they will be regular occurrences and not worth creating release notes for individually, but as the process gets started and people are migrating to beta it seems prudent to attempt keep people informed for now. Curious for others’ opinions.

[vadimcn]

The link above is wrong.
Also, perhaps the release date on the website should be updated as well?

[brson]

@vadimcn Thanks, both fixed.

[SimonSapin]

Is there an URL for downloading whatever is the latest beta? I’ve seen it recommended to use this in .travis.yml:

rust:
    - nightly
    - 1.0.0-beta

The latter entry expands to https://static.rust-lang.org/dist/rust-1.0.0-beta-x86_64-unknown-linux-gnu.tar.gz and so is stuck to that particular version, but https://static.rust-lang.org/dist/rust-beta-x86_64-unknown-linux-gnu.tar.gz is a 404 error.

[ruabmbua]

You could take a look into the source code of https://github.com/brson/multirust. It handles updating multiple toolchains, and allows to track a specific release channel like beta and nightly.

[brson]

@SimonSapin No, there is not presently a stable URL for downloading the current beta or current stable tarball. Discovering the URL of an installer from one of the release channels requires extra metadata (which rustup.sh knows how to find).

For now I think the right option is to update Travis to use rustup.sh, though if people are testing under Windows on Travis that won’t help them.

There are a some potential upcoming changes to this stuff.

After 1.0 I think we will begin just naming every beta artifact rust-beta-{triple}.tar.gz, as is done now with the nightlies, which will make your previous example work, but I don’t think Travis should rely on this, and it won’t help with ‘stable’.

After we move our HTTPS off cloudfront we’ll have options to perhaps rewrite stable URLs to the correct current release.

[blabaere]

This worked for me:

language: rust
rust: 1.0.0-beta.2

[SimonSapin]

For now I think the right option is to update Travis to use rustup.sh

That sounds right. I’ve filed https://github.com/travis-ci/travis-ci/issues/3704

though if people are testing under Windows on Travis that won’t help them.

Travis’s Rust support doesn’t seem to include Windows anyway. Does Travis run Windows at all?

This worked for me:

language: rust
rust: 1.0.0-beta.2

Sure, but are you gonna update it every few weeks for every one of your crates?

[brson]

Thanks for making the PR @SimonSapin.

[SimonSapin]

Not a PR, just an issue. This would be a non-trivial change to travis-build that I don’t know how to test. (Set up an entire local Travis instance?)

[SimonSapin]

Good news, someone made https://github.com/travis-ci/travis-build/pull/430 and it’s now deployed, so you have a .travis.yml like:

sudo: false
language: rust
rust:
  - nightly
  - beta

Version specifiers there are given as --spec arguments to rustup.sh.

[bluss]

Very nice! Is there a way to enable cargo feature flags (for unstable features) for just the nightly build? That should make sure all the code is tested for my crates.

[ogeon]

Travis has an environment variable for that. I decided to write a simple shell script and used it just as one would use cargo:

if [ "$TRAVIS_RUST_VERSION" = "nightly" ]; then
	cargo $@ --features nightly
else
	cargo $@
fi

calling it like this:

sh scripts/cargo.sh build -v

There may be a more robust solution, but this works fine for simple situations like this.

[bluss]

Here is what I ended up using. Adding feature flags in the nightly and skipping benchmarks in stable (beta right now).

---

.travis.yml

language: rust
rust:
  - nightly
  - beta
script:
  - ./travis_cargo.sh build --verbose
  - ./travis_cargo.sh test --verbose
  - ./travis_cargo.sh bench --verbose
  - ./travis_cargo.sh doc --verbose

---

travis_cargo.sh

#!/bin/sh

FEATURES=

if [ "$TRAVIS_RUST_VERSION" = "nightly" ]; then
    FEATURES="--features unstable"
else
    if [ "$1" = "bench" ]; then exit 0; fi
fi

exec cargo "$@" $FEATURES