PMで翻訳に関するコメントを送信してください。
Rust 1.0 の次期リリースには多くの重要なものが含まれていますが、最も重要なものは、セキュリティに常に焦点を当てているのと同様に、安定性を確保するための取り組みです。
バージョン1.0から、6週間のリリースサイクルと一連の「チャンネル」に進みます。 安定版リリースチャンネルは痛みのないアップデートを提供し、ナイトリービルドチャンネルは現在取り組んでいる機能へのアクセスを開拓者に提供します。
安定性の追求
Rustの初期の頃から、変更されていないのはセキュリティと変更の2つだけです。 Rustを開発する過程で、しばしば行き止まりに陥ったため、言語を変更する自由が絶対に必要でした。
しかしそれ以来、Rustは「成熟」しており、その重要な側面はかなり長い間変わっていません。 そのアーキテクチャは最終的に私たちにとって正しいようです。 さらに、Stableバージョン1.0のリリースを見越して抑制された、言語に対する真の関心を観察できるようになりました。
安定性の意味を明確にすることは非常に重要です。 これは、Rustが開発を停止するという意味ではありません。 言語の新しいバージョンを定期的にリリースし、ユーザーがプロジェクトの環境を頻繁に更新することを願っています。 ただし、このためには、更新プロセス自体に問題はありません。
非常に簡単な場合、私たちの責任は、あなたがRustを更新することを恐れないことを保証することです。 コードが安定版リリース1.0でコンパイルされている場合は、最小限の手間で安定版リリース1.xでもコンパイルする必要があります。
私たちの計画
Webブラウザの開発で最初に登場し、安定性を確保して停滞を防ぐために現在広く使用されている「トレイン」モデルのバージョンを使用します。
- 新しい機能は、メインブランチに直接追加されます。
- 毎日、メインブランチに基づく最後の成功したビルドは、新しいナイトリーリリースになります。
- 6週間ごとに、メインブランチの現在の状態からベータブランチが作成され、以前のベータバージョンが安定していると宣言されます。
つまり、ナイトリービルド、ベータビルド、安定版リリースの3つのリリースチャネルがあり、1つのチャネルから次のチャネルへの定期的なプロモーションが行われます。
新しい機能と新しいAPIは、それぞれ機能ゲートと安定性の属性を使用して不安定とマークされます。 不安定な機能と標準ライブラリAPIは、ナイトリービルドチャネルでのみ使用でき、明示的に使用に同意した場合にのみ使用できます。
一方、ベータ版と安定版のリリースには、安定版としてマークされている機能とAPIのみが含まれます。 これは、それらを使用するコードを壊さないように特別な注意が払われることを意味します。
よくある質問
説明されているプロセスには多くの詳細が関与しているので、RFCを公開します。RFCで詳細を説明します。 この投稿の残りの部分では、計画に関する最も重要な機能と潜在的な懸念に焦点を当てます。
1.0ではどの機能が安定しますか？
Rustエコシステムの既存のインフラストラクチャを分析して、最も使用されているライブラリ（クレート）とそれらが使用する機能ゲートを特定し、この安定化計画に基づいて構築しました。 良いニュース：現在アクティブに使用されている機能の大半は、リリース1.0で安定とマークされます。
- ほぼ完成した機能：構造オプション（列挙）、t およびデフォルトの新しいパラメーター、タプルのインデックス付け、およびスライスを作成するための構文。
- まだ作業が必要な言語の2つの重要な要素は、ボックス化されていないクロージャーと関連する型です。
- 最後に、重要な機能である1.0より前に解決する時間がない問題は、複数の（グロブ）インポート、マクロ、および構文拡張です。 ここでは、難しい決定を下す必要があります。
多くの議論の後、リリース1.0では複数のインポートとマクロを安定させることにしました。 globインポートの問題は、下位互換性を損なうことなく解決できると考えています。 マクロについては、既存の「マクロ定義」が徐々に改善されるまで、後で（改善された衛生状態で ）それらを定義する追加の方法を提供する可能性があります。 リリース1.0では、マクロのインポート/エクスポートを含むすべての既存のサポートが安定化されます。
一方、構文拡張機能は宣言できません。構文拡張機能は、安定した内部に完全にアクセスできるコンパイラプラグインです。 これは、コンパイラの内部デバイス全体が永久に修正されることを意味します。 そのため、拡張機能とコンパイラの間のより思慮深いインターフェイスを開発する必要があります。そのため、構文拡張機能は1.0の機能フラグのままです。
多くの重要な場合、構文拡張は従来のコード生成に置き換えることができ、そのサポートはまもなくCargoに含まれます。 ライブラリの作成者が構文拡張からリリース1.0に移行するのを支援します。 ただし、多数の拡張機能がこのモデルに適合しないため、1.0のリリース後、安定化は優先度が高くなります。
標準ライブラリのどの部分が1.0で安定しますか？
標準ライブラリは徐々に安定化されており、ほぼすべてのモジュールの計画があります。 標準ライブラリの機能の大部分は、1.0に対して安定とマークされることが予想されます。 さらに、APIの最も実験的な部分を別のライブラリ（クレート）に転送します。
標準ライブラリ外の安定性属性についてはどうですか？
ライブラリ開発者は、今日のように、コードの安定性属性を引き続き使用できます。 これらの属性は、デフォルトのRustリリースチャネルには関連付けられません。 つまり、安定したRustを使用してコンパイルする場合、標準ライブラリの安定したAPIのみを使用できますが、他のライブラリの実験要素を自由に試すことができます。 Rustリリースチャネルは、Rust自体 （コンパイラおよび標準ライブラリ）の簡単な更新を目的としています。
ライブラリ作成者は、 セマンティックバージョンの仕様に従うことになっています 。 まもなく、安定性属性とセマンティックバージョンの関係を定義するRFCを公開します。
安定版リリースで不安定な機能の使用を許可しないのはなぜですか？
安定版リリースで不安定な言語要素とライブラリを使用すると、3つの問題が発生します。
まず、Web開発の分野で何回観察できるかを、不安定なものを宣言するだけでは役に立ちません。 機能が少なくとも少し広く使用され始めるとすぐに、それらを変更するのは非常に困難です。 機能が原則として利用可能になるとすぐに、それらの使用を防ぐことは非常に困難です。 もともと機能を試すために設計されたWeb上のベンダープレフィックスなどのメカニズムは、事実上の標準になっています。
第二に、定義上、不安定な要素は不完全であり、常に作業が進行中です。 ただし、ベータ版と安定版リリースは指定された時間に「フリーズ」しますが、ライブラリ開発者は最新バージョンを使用したいと考えています。
最後に、特定のルールの実装を主張しないと、Rustの安定性を確保できません。 Rustの安定したリリースを使用する場合、次のリリースに向けて完全に大胆に更新できることをお約束します。 サードパーティのライブラリがRustの不安定性に依存する場合、これらのライブラリの作成者が3つのチャネルすべてに対して同時にライブラリをサポートすることで同じことを保証する場合にのみ、この約束を守ることができます。
エコシステム全体でこれらの問題を解決することは完全に非現実的であり、原則として必要ありません。 代わりに、何かが安定している場合、実際には安定であり、安定したチャネルは安定した機能のみを提供するというルールを確立します。
エコシステムは分割されますか？ リリース後も誰もがナイトリービルドを使用しませんか？
いいえ、エコシステムは分割されません。このアプローチは、そのサブセットのみを強調しています。 夜間チャンネルで作業する開発者は、言語の安定バージョン用に設計されたライブラリを自由に使用できます。 最も重要な機能とAPIは何らかの形で安定するため、時間の経過とともに不安定な世界にとどまる理由はますます少なくなります。
既存のエコシステムのほとんどが「安定」カテゴリに分類されるようにリリース1.0を計画しました。そのため、Rustを学習し始めたばかりの初心者は、安定リリース1.0の既存のライブラリの大半をすぐに使用できます。
どのような条件下で安定性が提供されますか？
追加の型注釈が必要になるように、コンパイラのバグを修正し、セキュリティホールを閉じ、型推論アルゴリズムを変更する権利を留保します。 Rustをアップグレードするときに、この種の変更が深刻な頭痛の種になることはないと考えています。
APIの安定性機能については、将来のRFCで概説されますが、一般的には、アップグレードが容易になるように考えられています。
Rustとそのエコシステムは、現在と同様に積極的に発展し続けますか？
間違いなくはい！ 常に新しいブランチがメインブランチに反映されるため、「トレーニング」モデルは開発のペースを遅くせず、人為的な遅延を引き起こしません。 私たちの素晴らしいコミュニティの支援により、Rustは常に非常に速く発展しており、ペースは将来的にのみ加速すると確信しています。