Rust 1.15 prerelease testing holds the build environment steady
The final testing request makes archived builds available while deferring buildbot changes for PowerPC and s390x. It separates validating a candidate from changing the machinery that produces it.
A release candidate can change even when the compiler source does not, because the environment producing its binaries is also part of the process. The Rust 1.15 prerelease request contains a concrete decision about that risk. Builds are available for testing, but recently prepared buildbot fixes for PowerPC and s390x are not included. The release team has chosen to keep the production environment steady immediately before release.
The January 31 thread says Rust 1.15 is scheduled for Thursday and points testers to the dated archive. It gives a rustup command for selecting the candidate and explains the omitted buildbot changes. This is an invitation to examine the available artifacts, with a stated limitation, rather than an announcement that the stable release has already happened.
I am interested in Rust as a systems language because its semantics make constraints explicit. Release engineering needs the same clarity. A precise statement about which build environment produced a candidate is more useful than treating every available fix as something that must enter the last build.
The candidate has a dated identity
The thread identifies an archive under 2017-01-31 and gives a toolchain name incorporating that date. A tester can therefore select the intended artifacts without relying on whatever a moving channel happens to contain when the command runs.
rustup update stable-2017-01-31
This is the command supplied by the contemporary request. The stable part of the identifier does not turn the request into a completed release announcement. In context, it is how the team asks testers to obtain this dated prerelease build.
That specificity is useful when results come from different machines over several days. A report against an unnamed recent compiler leaves maintainers another question to resolve before investigating. Naming the dated candidate gives both sides a common starting point. It does not replace reporting the platform or the program that failed, but it identifies the artifact under examination.
The rustup introduction explains why toolchain management supports this workflow. It describes keeping compiler and standard-library copies side by side and choosing a toolchain for a command. Testing a candidate need not require replacing every normal development invocation with that compiler.
A missing deployment is different from a missing patch
The opening post says the buildbot fixes had not been deployed, a fact discovered the previous night. Maintainers judged it too risky to change that environment so close to release and planned to deploy the changes for the next beta instead. The message makes the reason for omission visible to the contributor who supplied them.
This is a decision about timing and evidence. A prepared infrastructure fix may be desirable, but deploying it changes the conditions under which release artifacts are produced. The remaining prerelease period would then have to provide confidence in both the compiler candidate and the altered build machinery.
The reply accepts the decision and says changing the build environment days before release would be too risky. It also notes that the contributor can rebuild earlier releases with the newer toolchains if necessary. That describes a local option for someone with the relevant capability. It does not imply that all downstream users should reproduce the release infrastructure themselves.
The thread does not describe the technical contents of the PowerPC and s390x fixes in enough detail to infer a specific compiler defect. It would therefore be inaccurate to invent a failing instruction sequence or claim those architectures cannot run the candidate. What the source establishes is the omission of deployment changes and the rationale for deferring them.
The distinction also gives testers a useful boundary for discussion. A result from the dated distribution concerns the distribution being considered for release. A locally rebuilt compiler with different native tools can supply additional information, but it represents another environment and needs to be identified accordingly.
Testing validates an artifact and its assumptions
Prerelease testing is useful because downstream programs combine language features, libraries, and build scripts in ways the compiler suite may not cover. The dated candidate makes that testing actionable. A successful project build supplies evidence about one real combination, while a failure gives maintainers a concrete case to examine before the release.
The buildbot decision adds another dimension. Holding the environment steady preserves the meaning of existing candidate results. If the team silently replaced a toolchain component during the same window, a report might refer to conditions different from those that produced the final artifact. Naming an omission helps reviewers understand what the results can establish.
I prefer this explicit limit to a last-minute promise that every known improvement is included. The immediate task is to evaluate the available candidate and report problems against it. The thread leaves the deferred infrastructure work attached to the next beta, where it can receive a longer period of testing under the changed build conditions.