diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index bafc8ef227..d4dcbbf715 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -99,6 +99,6 @@ jobs: - name: Check for broken links run: | curl -sSLo linkcheck.sh \ - https://raw.githubusercontent.com/rust-lang/rust/master/src/tools/linkchecker/linkcheck.sh + https://raw.githubusercontent.com/rust-lang/rust/HEAD/src/tools/linkchecker/linkcheck.sh # Cannot use --all here because of the generated redirect pages aren't available. sh linkcheck.sh book diff --git a/README.md b/README.md index 29c9083adb..4c62b1a73b 100644 --- a/README.md +++ b/README.md @@ -27,7 +27,7 @@ Building the book requires [mdBook], ideally the same version that rust-lang/rust uses in [this file][rust-mdbook]. To get it: [mdBook]: https://github.com/rust-lang/mdBook -[rust-mdbook]: https://github.com/rust-lang/rust/blob/master/src/tools/rustbook/Cargo.toml +[rust-mdbook]: https://github.com/rust-lang/rust/blob/HEAD/src/tools/rustbook/Cargo.toml ```bash $ cargo install mdbook --locked --version diff --git a/nostarch/appendix.md b/nostarch/appendix.md index 1dee77cf62..7a68652b70 100644 --- a/nostarch/appendix.md +++ b/nostarch/appendix.md @@ -777,6 +777,10 @@ the Translations label at *https://github.com/rust-lang/book/issues?q=is%3Aopen+ * हिंदी at *https://github.com/venkatarun95/rust-book-hindi* * ไทย at *https://github.com/rust-lang-th/book-th* * Danske at *https://github.com/DanKHansen/book-dk* +* O’zbek at *https://github.com/rust-lang-uz/book* +* Tiếng Việt at *https://github.com/tuanemdev/rust-book-vn* +* Italiano at *https://nixxo.github.io/rust-lang-book-it/* +* বাংলা at *https://github.com/IsmailHosenIsmailJames/rust-book-bn* ## Appendix G - How Rust is Made and “Nightly Rust” @@ -799,7 +803,7 @@ bring you new features, fewer bugs, and faster compile times. ### Choo, Choo! Release Channels and Riding the Trains Rust development operates on a *train schedule*. That is, all development is -done on the `master` branch of the Rust repository. Releases follow a software +done in the main branch of the Rust repository. Releases follow a software release train model, which has been used by Cisco IOS and other software projects. There are three *release channels* for Rust: @@ -813,7 +817,7 @@ try out experimental new features may use nightly or beta. Here’s an example of how the development and release process works: let’s assume that the Rust team is working on the release of Rust 1.5. That release happened in December of 2015, but it will provide us with realistic version -numbers. A new feature is added to Rust: a new commit lands on the `master` +numbers. A new feature is added to Rust: a new commit lands on the main branch. Each night, a new nightly version of Rust is produced. Every day is a release day, and these releases are created by our release infrastructure automatically. So as time passes, our releases look like this, once a night: @@ -823,7 +827,7 @@ nightly: * - - * - - * ``` Every six weeks, it’s time to prepare a new release! The `beta` branch of the -Rust repository branches off from the `master` branch used by nightly. Now, +Rust repository branches off from the main branch used by nightly. Now, there are two releases: ``` @@ -844,8 +848,8 @@ beta: * Let’s say a regression is found. Good thing we had some time to test the beta release before the regression snuck into a stable release! The fix is applied -to `master`, so that nightly is fixed, and then the fix is backported to the -`beta` branch, and a new release of beta is produced: +to the main branch, so that nightly is fixed, and then the fix is backported to +the `beta` branch, and a new release of beta is produced: ``` nightly: * - - * - - * - - * - - * - - * @@ -904,9 +908,9 @@ each version is supported for six weeks. There’s one more catch with this release model: unstable features. Rust uses a technique called “feature flags” to determine what features are enabled in a -given release. If a new feature is under active development, it lands on -`master`, and therefore, in nightly, but behind a *feature flag*. If you, as a -user, wish to try out the work-in-progress feature, you can, but you must be +given release. If a new feature is under active development, it lands on the +main branch, and therefore, in nightly, but behind a *feature flag*. If you, as +a user, wish to try out the work-in-progress feature, you can, but you must be using a nightly release of Rust and annotate your source code with the appropriate flag to opt in. @@ -975,8 +979,8 @@ there’s consensus to accept or reject the feature. If the feature is accepted, an issue is opened on the Rust repository, and someone can implement it. The person who implements it very well may not be the person who proposed the feature in the first place! When the implementation is -ready, it lands on the `master` branch behind a feature gate, as we discussed -in the “Unstable Features” section. +ready, it lands on the main branch behind a feature gate, as we discussed in +the “Unstable Features” section. After some time, once Rust developers who use nightly releases have been able to try out the new feature, team members will discuss the feature, how it’s diff --git a/packages/tools/src/bin/link2print.rs b/packages/tools/src/bin/link2print.rs index 46244a2df0..b763828a77 100644 --- a/packages/tools/src/bin/link2print.rs +++ b/packages/tools/src/bin/link2print.rs @@ -364,7 +364,7 @@ note: required by `std::fmt::Display::fmt` [I'm a reference-style link][Arbitrary case-insensitive reference text] -[I'm a relative reference to a repository file](../blob/master/LICENSE) +[I'm a relative reference to a repository file](../blob/HEAD/LICENSE) [You can use numbers for reference-style link definitions][1] @@ -387,7 +387,7 @@ I'm an inline-style link with title at *https://www.google.com* I'm a reference-style link at *https://www.mozilla.org* -I'm a relative reference to a repository file at *../blob/master/LICENSE* +I'm a relative reference to a repository file at *../blob/HEAD/LICENSE* You can use numbers for reference-style link definitions at *http://slashdot.org* diff --git a/redirects/release-channels.md b/redirects/release-channels.md index 6e01e227fe..bf2f87315d 100644 --- a/redirects/release-channels.md +++ b/redirects/release-channels.md @@ -22,7 +22,7 @@ You can check out other resources that describe release channels. [1]: https://doc.rust-lang.org/1.30.0/book/first-edition/release-channels.html [2]: appendix-07-nightly-rust.html -[3]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md -[4]: https://github.com/rust-lang-nursery/rustup.rs/blob/master/README.md#keeping-rust-up-to-date +[3]: https://github.com/rust-lang/rfcs/blob/HEAD/text/0507-release-channels.md +[4]: https://github.com/rust-lang-nursery/rustup.rs/blob/HEAD/README.md#keeping-rust-up-to-date [5]: https://www.rust-lang.org/en-US/tools/install diff --git a/src/appendix-07-nightly-rust.md b/src/appendix-07-nightly-rust.md index 5246d72825..7108441fa3 100644 --- a/src/appendix-07-nightly-rust.md +++ b/src/appendix-07-nightly-rust.md @@ -19,7 +19,7 @@ bring you new features, fewer bugs, and faster compile times. ### Choo, Choo! Release Channels and Riding the Trains Rust development operates on a _train schedule_. That is, all development is -done on the `master` branch of the Rust repository. Releases follow a software +done in the main branch of the Rust repository. Releases follow a software release train model, which has been used by Cisco IOS and other software projects. There are three _release channels_ for Rust: @@ -33,7 +33,7 @@ try out experimental new features may use nightly or beta. Here’s an example of how the development and release process works: let’s assume that the Rust team is working on the release of Rust 1.5. That release happened in December of 2015, but it will provide us with realistic version -numbers. A new feature is added to Rust: a new commit lands on the `master` +numbers. A new feature is added to Rust: a new commit lands on the main branch. Each night, a new nightly version of Rust is produced. Every day is a release day, and these releases are created by our release infrastructure automatically. So as time passes, our releases look like this, once a night: @@ -43,7 +43,7 @@ nightly: * - - * - - * ``` Every six weeks, it’s time to prepare a new release! The `beta` branch of the -Rust repository branches off from the `master` branch used by nightly. Now, +Rust repository branches off from the main branch used by nightly. Now, there are two releases: ```text @@ -64,8 +64,8 @@ beta: * Let’s say a regression is found. Good thing we had some time to test the beta release before the regression snuck into a stable release! The fix is applied -to `master`, so that nightly is fixed, and then the fix is backported to the -`beta` branch, and a new release of beta is produced: +to the main branch, so that nightly is fixed, and then the fix is backported to +the `beta` branch, and a new release of beta is produced: ```text nightly: * - - * - - * - - * - - * - - * @@ -124,9 +124,9 @@ each version is supported for six weeks. There’s one more catch with this release model: unstable features. Rust uses a technique called “feature flags” to determine what features are enabled in a -given release. If a new feature is under active development, it lands on -`master`, and therefore, in nightly, but behind a _feature flag_. If you, as a -user, wish to try out the work-in-progress feature, you can, but you must be +given release. If a new feature is under active development, it lands on the +main branch, and therefore, in nightly, but behind a _feature flag_. If you, as +a user, wish to try out the work-in-progress feature, you can, but you must be using a nightly release of Rust and annotate your source code with the appropriate flag to opt in. @@ -195,8 +195,8 @@ there’s consensus to accept or reject the feature. If the feature is accepted, an issue is opened on the Rust repository, and someone can implement it. The person who implements it very well may not be the person who proposed the feature in the first place! When the implementation is -ready, it lands on the `master` branch behind a feature gate, as we discussed -in the [“Unstable Features”](#unstable-features) section. +ready, it lands on the main branch behind a feature gate, as we discussed in +the [“Unstable Features”](#unstable-features) section. After some time, once Rust developers who use nightly releases have been able to try out the new feature, team members will discuss the feature, how it’s