What Canonical announced for Ubuntu 26.10
Canonical announced Ubuntu 26.10, Stonking Stingray, on October 15, 2026. It listed Rust 1.97.1 and announced Spring AI availability on Ubuntu Desktop through the Spring devpack. Canonical says the release coincides with the Rust devpack. Spring support predates this release; Canonical’s new announcement concerns Spring AI availability. Sources: Canonical
Canonical describes the Rust devpack as an interactive installer with choices for Rust channels, editors and utilities. The Rust examples below use documented mechanisms. The Spring and continuous integration, or CI, recommendations are a proposed planning checklist, not a verified image-preservation workflow. Sources: Canonical on GitHub
Create a Rust project with an explicit compiler
Record the chosen utilities and their versions in the project’s setup instructions. Ubuntu also documents archive packages and a Rustup snap as separate installation routes. Check the active compiler instead of assuming its version. Sources: Ubuntu
The first example below creates a small command-line project using the Cargo workflow in Ubuntu’s introductory tutorial. The release announcement lists Rust 1.97.1, but does not establish its availability through Rustup. Install the chosen version and components through Rustup before creating the toolchain file or building. If 1.97.1 fails to install, use a verified available version. Use that version consistently in the installation command, toolchain file and CI commands. Sources: Canonical, Ubuntu
Rustup supports repository toolchain files with version, profile and component selections. Keep this file with the source so compiler changes become part of code review. Sources: The Rust Project
rustup toolchain install 1.97.1 --profile minimal \
--component rustfmt --component clippyContinue only after that installation succeeds, substituting the verified version below if necessary.
cargo new workstation-check
cd workstation-check# rust-toolchain.toml
[toolchain]
channel = "1.97.1"
profile = "minimal"
components = ["rustfmt", "clippy"]Verify compiler selection and lock dependencies
After successful installation, inspect the active toolchain before building. Rustup allows command-line selections and an environment variable to override a repository file. Directory overrides also affect selection. The proposed sequence below prints the effective compiler and Cargo versions. It generates the initial dependency lockfile before building and testing. Sources: The Rust Project
rustup show
rustc -Vv
cargo -V
cargo generate-lockfile
cargo build --locked
cargo test --lockedCommit rust-toolchain.toml, Cargo.toml and Cargo.lock together. Cargo normally preserves locked resolutions where possible, but changed requirements can cause it to update the lockfile. Locked builds fail when dependency resolution would require a change. Sources: The Rust Project
The proposed CI commands below explicitly select the compiler and enforce the dependency lock. Use the same verified available version recorded in rust-toolchain.toml. Keep lockfile updates in a reviewed dependency-update workflow. Sources: The Rust Project
cargo +1.97.1 build --locked
cargo +1.97.1 test --lockedCapture native build inputs separately. Ubuntu’s setup guide notes that native dependencies can require the build-essential package. Record the linker, native libraries, operating-system packages, target architecture and external generators. Compiler selection and dependency locking address different parts of that inventory. The table below pairs documented mechanisms with recommended records for comparing environments. Sources: Ubuntu
Table
Build controls and the records to preserve
| Layer | Documented mechanism | Recommended record |
|---|---|---|
| Rust compiler | Repository toolchain file and overrides | Exact release, components and active selection |
| Rust dependencies | Cargo lockfile and locked builds | Committed lockfile |
| Native tools | Separate native build dependencies | Package versions, linker and architecture |
Record Spring AI application inputs
Record the installed development tools and their versions. Plan how to preserve the build inputs separately from recording their versions.
Commit the generated application instead of regenerating it during each CI run. Record the exact resolved Spring AI version and Java Development Kit, or JDK, build alongside it.
Treat a successful response as an application check rather than a reproducibility measurement. If inference behavior is an acceptance criterion, record the model artifact, quantization, inference engine, configuration and hardware. Assess application behavior and generated answers separately.
Plan build-image preservation for CI
For a proposed CI workflow, plan how to create, retain and reuse a build image. Include registry retention and recording the published image digest in that plan. Preserve the generated project, build configuration and dependency records alongside that image reference.
Test repeated builds and schedule updates
For an acceptance test, start with two clean machines using the same specifications. Record build-tool versions. Then build from the committed project files and preserved image. Compare dependency graphs and artifact hashes separately. Matching dependencies alone does not prove byte-identical binaries. For Spring AI, separate application tests using a controlled service substitute from tests of actual inference.
Plan updates alongside preservation. Ubuntu lists support for 26.10 through July 2027, giving teams a migration deadline. Schedule image rebuilds and dependency updates as reviewed changes, then repeat the acceptance checks. Before wider adoption, ask Canonical how to preserve exact build inputs. Also ask whether Rust selections can be exported and replayed without interaction. Sources: Canonical