G - Rustはどのように作られるかと「Nightly Rust」

付録 G - Rust の作られ方と「Nightly Rust」

この付録では、Rust がどのように作られているのか、そしてそれが Rust 開発者であるあなたにどのような影響を与えるのかを扱います。

停滞なき安定性

Rust は言語として、あなたのコードの安定性を_非常に_重視しています。私たちは、 Rust が安心してその上に構築できる盤石な基盤であってほしいと考えています。もし物事が絶えず変わっていたら、それは不可能でしょう。同時に、新機能を試験できなければ、重要な欠陥がリリース後、つまりもう変更できなくなってからでないと見つからないかもしれません。

この問題に対する私たちの解決策が、「停滞なき安定性」と呼ぶものです。そして、私たちの指針は次のとおりです。stable Rust の新しいバージョンへのアップグレードを恐れる必要は決してない、ということです。アップグレードのたびに苦痛がないだけでなく、新機能、より少ないバグ、そしてより高速なコンパイル時間ももたらされるべきです。

シュッシュッ！リリースチャネルと列車に乗ること

Rust の開発は_列車ダイヤ方式_で進められています。つまり、すべての開発は Rust リポジトリの main ブランチで行われます。リリースは、Cisco IOS やほかのソフトウェアプロジェクトでも使われてきた、ソフトウェアのリリーストレインモデルに従います。 Rust には 3 つの_リリースチャネル_があります。

Nightly
Beta
Stable

ほとんどの Rust 開発者は主に stable チャネルを使いますが、実験的な新機能を試したい人は nightly や beta を使うことがあります。

開発とリリースのプロセスがどのように機能するか、例を見てみましょう。Rust チームが Rust 1.5 のリリースに取り組んでいると仮定します。そのリリースは 2015 年 12 月に実際に行われましたが、現実的なバージョン番号の例として使えます。 Rust に新機能が追加されると、新しいコミットが main ブランチに入ります。毎晩、新しい nightly 版の Rust が作成されます。毎日がリリース日であり、これらのリリースは私たちのリリース基盤によって自動的に作成されます。したがって、時間がたつにつれて、リリースは毎晩次のようになります。

nightly: * - - * - - *

6 週間ごとに、新しいリリースを準備する時期が来ます！ Rust リポジトリの beta ブランチは、nightly が使っている main ブランチから分岐します。これで、リリースは 2 つになります。

nightly: * - - * - - *
                     |
beta:                *

ほとんどの Rust ユーザーは beta リリースを積極的には使いませんが、 CI システムで beta に対してテストを行い、Rust が起こりうるリグレッションを見つけるのを助けます。その間も、nightly のリリースは毎晩続きます。

nightly: * - - * - - * - - * - - *
                     |
beta:                *

リグレッションが見つかったとしましょう。リグレッションが stable リリースに紛れ込む前に beta リリースをテストする時間があって助かりました！修正は main ブランチに適用され、nightly が直されます。その後、その修正は beta ブランチにもバックポートされ、新しい beta リリースが作成されます。

nightly: * - - * - - * - - * - - * - - *
                     |
beta:                * - - - - - - - - *

最初の beta が作成されてから 6 週間後、stable リリースの時期になります！ stable ブランチは beta ブランチから作成されます。

nightly: * - - * - - * - - * - - * - - * - * - *
                     |
beta:                * - - - - - - - - *
                                       |
stable:                                *

やった！ Rust 1.5 の完成です！しかし、1 つ忘れていました。6 週間が経過したので、Rust の_次の_バージョンである 1.6 の新しい beta も必要です。そこで、stable が beta から分岐したあと、次のバージョンの beta が再び nightly から分岐します。

nightly: * - - * - - * - - * - - * - - * - * - *
                     |                         |
beta:                * - - - - - - - - *       *
                                       |
stable:                                *

これが「列車モデル」と呼ばれるのは、6 週間ごとに 1 つのリリースが「駅を出発」するものの、stable リリースとして到着する前に、beta チャネルを通る旅をしなければならないからです。

Rust は時計仕掛けのように、6 週間ごとにリリースされます。ある Rust のリリース日を知っていれば、次のリリース日もわかります。6 週間後だからです。リリースが 6 週間ごとに予定されていることのよい点は、次の列車がすぐに来ることです。ある機能がたまたま特定のリリースに間に合わなくても、心配する必要はありません。次のものがすぐにやってくるからです！これにより、十分に磨かれていないかもしれない機能をリリース期限直前に滑り込ませようとするプレッシャーを減らせます。

このプロセスのおかげで、いつでも Rust の次のビルドを試し、アップグレードが容易であることを自分で確認できます。beta リリースが期待どおりに動かなければ、チームに報告し、次の stable リリースが行われる前に修正してもらえます！ beta リリースで何かが壊れることは比較的まれですが、rustc も依然としてソフトウェアであり、バグは実際に存在します。

メンテナンス期間

Rust プロジェクトは、最新の stable バージョンをサポートします。新しい stable バージョンがリリースされると、古いバージョンはサポート終了（EOL）を迎えます。これは各バージョンが 6 週間サポートされることを意味します。

不安定な機能

このリリースモデルには、もう 1 つ注意点があります。それが不安定な機能です。Rust はあるリリースでどの機能を有効にするかを決めるために、「フィーチャーフラグ」と呼ばれる手法を使います。新機能が活発に開発中であれば、それは main ブランチに入り、したがって nightly にも入りますが、フィーチャーフラグ の背後に置かれます。ユーザーとして開発途中の機能を試したければできますが、そのためには nightly リリースの Rust を使い、オプトインするために適切なフラグをソースコードに付けなければなりません。

beta または stable リリースの Rust を使っている場合、フィーチャーフラグは一切使えません。これこそが、新機能を永久に stable だと宣言する前に、実際に使ってみられるようにする鍵です。最先端にオプトインしたい人はそうできますし、盤石な体験を望む人は stable にとどまり、自分のコードが壊れないとわかります。停滞なき安定性です。

本書には stable な機能に関する情報しか含まれていません。開発中の機能はまだ変化しており、この本が書かれた時点と、それらが stable ビルドで有効になる時点とでは、きっと異なっているからです。nightly 専用機能のドキュメントはオンラインで見つけられます。

Rustup と Rust Nightly の役割

Rustup を使うと、Rust の異なるリリースチャネルをグローバルまたはプロジェクトごとに簡単に切り替えられます。デフォルトでは stable Rust がインストールされています。たとえば nightly をインストールするには、次のようにします。

$ rustup toolchain install nightly

rustup でインストールしたすべての_ツールチェーン_（Rust のリリースと関連コンポーネント）も確認できます。以下は、著者の 1 人の Windows コンピューターでの例です。

> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc

ご覧のとおり、stable ツールチェーンがデフォルトです。ほとんどの Rust ユーザーは、ほとんどの時間 stable を使います。たいていは stable を使いたいが、最先端の機能を使いたいために、特定のプロジェクトでは nightly を使いたいということもあるでしょう。そのためには、そのプロジェクトのディレクトリで rustup override を使って、そのディレクトリにいるときに rustup が使うべきツールチェーンとして nightly を設定できます。

$ cd ~/projects/needs-nightly
$ rustup override set nightly

これで、~/projects/needs-nightly の中で rustc または cargo を呼び出すたびに、rustup は stable Rust をデフォルトにしていても、stable Rust ではなく nightly Rust を使っていることを保証してくれます。Rust のプロジェクトをたくさん持っていると、これはとても便利です！

RFC プロセスとチーム

では、こうした新機能についてはどうやって知るのでしょうか。Rust の開発モデルは、Request For Comments（RFC）プロセス に従っています。Rust に改善を加えたい場合は、RFC と呼ばれる提案を書くことができます。

Rust を改善するための RFC は誰でも書くことができ、それらの提案は、多くの分野別サブチームで構成される Rust チームによってレビューされ、議論されます。Rust の Web サイトにはチームの完全な一覧があり、そこにはプロジェクトの各分野、つまり言語設計、コンパイラ実装、インフラストラクチャ、ドキュメントなどのチームが含まれています。適切なチームが提案とコメントを読み、自分たちでもコメントを書き、最終的にその機能を受け入れるか拒否するかについて合意が形成されます。

機能が受け入れられると、Rust リポジトリに issue が作成され、誰かがその実装を行えます。それを実装する人は、最初にその機能を提案した人とは限りません！実装の準備が整うと、「不安定な機能」セクションで説明したように、機能ゲートの背後に置かれた状態で main ブランチに入ります。

しばらくすると、nightly リリースを使う Rust 開発者が新しい機能を試せるようになり、チームメンバーはその機能と、nightly 上でそれがどう機能したかを議論し、それを stable Rust に入れるべきかどうかを決定します。前に進めると決まれば、機能ゲートは取り除かれ、その機能は stable と見なされるようになります！その機能は train に乗って、Rust の新しい stable リリースへと入ります。

Keyboard shortcuts