Skip to content

Release cycle ja JP

ArchiBot edited this page Jun 2, 2026 · 19 revisions

リリースサイクル

ASFは、 A.B.C.D として記述された4つの数字を持つ一般的なC#バージョン管理を使用します。 それぞれのバージョンは常に凍結されており、そこからビルドされた固定ソースコードを指します(リリースとバンドルされています)。 当社のホスティングプロバイダ(GitHub)が無期限に保存されている限り、以前に公開されたバージョンを削除するつもりはありません。 自動コピーを作らなくても安全に転がせます

一般的に、ASF のバージョニングについては、semverMAJOR.MINOR.PATCH バージョニングにできるだけ従うようにしています。これは下位 3 つの番号、つまり B.C.D に適用されます。 これらの3つの数字はASFのコードに直接関係しています。 最も重要な `` 数字は、通常ASFコードベース自体を超えるスコープでの変更を示します。 非常に頻繁にプログラムの基礎に影響を与えます

ASF プロジェクトとしては、おおよそ月に 1 回の機能リリースを目指しており、これは C 番号の増加で示されます。 そのようなリリースを可能にするために、上級ユーザー向けの小規模なプレリリースを用意しています。これは変更の小さなマイルストーンとして機能し、前回のプレリリース以降に注目すべき変更が十分にたまった時点で、必要に応じてリリースされます。 最終的に 最終的なプレリリースが安定して成熟していると判断された場合、 既知の重大な回帰がなく、 以前の安定したリリースと比較して修正されるべきです。 新安定版に昇格すると同時に次の月次の月次サイクルを開放する

プレリリースが比較的安定していることを確認するために最善を尽くしています。 プレリリースは、本番環境で実行する場合は慎重に評価する必要があることに注意してください。 プレリリースには重大なバグや壊れた機能が含まれている可能性があります。そもそもプレリリースを公開しているのは、まさに安定版ビルドでそのような混乱を避け、信頼できるソフトウェアを提供するためです。

潜在的に不安定なソフトウェアを使用することから生じるリスク増加を受け入れたくない場合。 プレリリースビルド の使用を避け、代わりに 最新安定 ビルドを使用してください。 大多数のユーザーには適しています

一方、 あなた自身を上級者と見なし、誰にとっても新しいリリースをテストするのを手伝いたいと思うなら - あなたはそれを試してフィードバックを提供することを歓迎しています 特に現在の安定版には存在しないバグや問題に関してはね

サイクル内の変更量にもよりますが、通常は(前回の安定版から)C バージョンが 1 回上がり、各プレリリースでは必要に応じて D が上がります。 しかし、はるかに大きなスコープで変更を導入する場合、特に変更を破ります。 サイクルは B または `` バンプから始まる可能性があります。このようなスイッチは、現在のリリースサイクルが通常よりも不安定になる可能性があることを示します。 慎重にテストするべきです

私たちが行う semver 上の変更は、以前にリリースされた安定版のみを基準にしていることに注意してください。サイクル内のプレリリース同士のバージョニングは追跡していません。つまり、以前に安定版としてマークされたリリースが 1.0.0.X 系である限り、1.0.1.2 には 1.0.1.1 になかった新機能が含まれている場合があります。 同様に、同じサイクルからの2つのプレリリースでも大きな変更が発生する可能性があります。 新しく導入された機能などの最終的な形状を決めているときは特にそうです

バージョンバンプ Semver 変更の例
A 主要な.NETランタイムの変更、基盤の変更、ASFのコードベースを超えた変更、あなたの猫を食べるかもしれないもの
B Major 小規模な.NETランタイムの変更、ASFコードベースの変更、マイナーな分類を超えるメジャーなコードの編集
C Minor 新しい月次サイクル、通常、既存の設定を壊さない新しい機能、コマンド、設定プロパティ、その他の変更を導入します
D パッチ 既存のサイクルの一部である新しいプレリリース(より重要な数字で示されます) 必要以上のコード変更を導入しない既存の安定版のリリースへの重要なバグ修正

新しく導入された機能や変更は、しばらくの間、ドキュメント化されていない場合があることに注意してください(Wiki など)。通常、ドキュメントは対象機能の最終的なコードが完成してから作成されます(現在作業中の機能を変更するたびにドキュメントを書き直す手間を省くためです)。 プレリリースには、まだ最終フォームを持たない進行中のコードが含まれている可能性があるため、 ドキュメントは開発の後半に到着するかもしれません。 同じことがプレリリースで使用できない可能性がある一般的な changelog にも適用されます。 したがって、プレリリースを使用することにした場合は、ASF を時々コミットするように準備してください。 もちろん、ドキュメントが存在しない状態はプレリリースにのみ適用されます。各安定版は、リリースされた時点で必ず完全な変更履歴と Wiki 上のドキュメントを備えている必要があります。

あるバージョンを別のバージョンと比較する正確なchangelogは、コミットとコードの変更を通じて、GitHubでいつでも利用できます。 リリースでは、最後の安定版と現在のリリースの間で重要と考えられる変更のみを記録する傾向があります。 このような簡単な変更履歴は完全なものではありません。 ですから、あるバージョンと別のバージョン(依存関係のアップグレードなど)で起こったすべての変更を見たい場合は、 GitHub比較 を使用してください。

ASFプロジェクトは、 継続的インテグレーションプロセス によって供給されます。 すべてのビルドは再現性があるはずです。 ですから、与えられたバージョンのソース(リリースに含まれる)をつかんで、プリコンパイルされたバイナリを通して入手可能なものと同じ結果を自分でコンパイルするのは問題ではありません。 通常、システムが動作している限り、リリースされたバイナリはCIプロセスから直接リリースされます。

Clone this wiki locally