ファイル冒頭にタイトルを書きます。タイトルにRFC番号を含める必要はありません。
- Revision History
- Abstract
- Specification
- Examples
- Motivation
- Rationale
- Backwards Compatibility
- Rejected Ideas
- Open Issues
- dev の使用には不便な点があるため alpha に変更しました。 (Rejected Ideasを参照)
文書の内容をまとめた概要を書きます。
JDim のバージョンフォーマットを変更し、開発中であることを表す alpha タグを導入します。
Note
alpha タグはGitタグとして作成するものではなく、
jdim --versionで表示するバージョン情報に含まれる開発段階を表すタグ(リリース修飾子)です。
機能の追加や変更を提案するときは仕様を書きます。
リリース後、最初の更新作業開始時に master ブランチのバージョンに alpha タグを追加して、開発中のバージョンであることを明示します。
- 開発中バージョンのフォーマットは
<次期リリースの番号>-alpha<日付>とします。 - 機能フリーズの期間に入ったとき beta タグに更新します。
現時点では、開発中バージョンのリリースを計画していないため、このRFCでは扱いません。
alpha タグを用いたバージョンの例:
- 0.13.0-alpha20240820
ユーザーが提案された機能をどのように使うのか例を書きます。
バージョン表記例:
| 状態 | 現行バージョン表記 | 更新案バージョン表記 |
|---|---|---|
| 0.12.0 リリース | 0.12.0-20240706 | 0.12.0-20240706 |
| 0.13.0 開発中 | 0.12.0-20240820 | 0.13.0-alpha20240820 🆕 |
| 0.13.0 機能フリーズ | 0.13.0-beta20241225 | 0.13.0-beta20241225 |
| 0.13.0 リリース | 0.13.0-20250110 | 0.13.0-20250110 |
※バージョンは例です。実際のバージョンとは異なります。
提案が必要になった背景や動機を書きます。
JDim のバージョンは番号、開発段階タグ、日付の3つで構成されています。
| 区分 | 説明 |
|---|---|
| 番号 | ドット(.)で区切られた3つの数値(メジャー . マイナー . マイクロ) |
| 開発段階タグ | 開発段階を表す省略可能な文字列です。(下記に具体的な説明) |
| 日付 | ソースコードが修正された日時、形式は YYYYMMDD, 例えば2024年7月10日なら 20240710 となります。 |
- 番号の各桁は独立した数値として扱われ、9 の次は 10 となります。例えば、0.9.0 の次のバージョンは 0.10.0 になります。
- バージョンのフォーマットは
<番号>-<開発段階タグ><日付>となります。 - 機能フリーズ期間中のバージョンは beta タグが付与されて
<番号>-beta<日付>となります。 - リリースのバージョンは開発段階タグが省略されて
<番号>-<日付>となります。
例:
- 0.13.0-beta20241225
- 0.13.0-20250110
開発中のバージョンはリリースから番号が変わらず日付が更新されていきます。
リリース後に修正が加えられてもバージョン番号が変わらなければ、一見して最新版かそうでないか判別できません。 このため、ユーザーがリリース版と開発版のどちらを使っているか判断しづらく、issue や掲示板での対応が難しくなっています。
Specificationに書かれた解決策を選んだ理由を書きます。
"alpha" は多くのソフトウェア(ブラウザや開発ツールなど)で開発段階のバージョンや開発版リリースに使用されています。 そのため、他の案より開発者やテスターではないユーザーに対しても開発段階であると伝わりやすいです。
リリース後すぐに alpha タグを付与しない理由は以下の通りです。
- リリース直後はsnapパッケージのビルドが完了していないため。
- リリース後にGitリポジトリからソースを更新するユーザーに配慮するため。
参考資料
- プログラミング言語Pythonのパッケージ仕様にまとめられているバージョンの付け方
後方互換性への影響を書きます。
alpha タグは新しいバージョンのみに追加されます。
ビルドスクリプトなどで beta タグによって処理を分岐させている場合、 alpha タグの存在も考慮するように条件分岐を追加する必要があります。
採用しなかった他のアイデアと却下の理由を書きます。
-
nightly
理由: 毎日更新される開発バージョンに使用されますが、 JDim は CI/CD でsnapパッケージを毎日更新しているわけではないため、不採用としました。 -
weekly や monthly
理由: 毎週/毎月更新される開発バージョンに使用されますが、定期的リリースを行わない場合は適切ではないため、不採用としました。 -
canary
理由: Webブラウザ Google Chrome やその派生物で使用されていますが、 JDim は Chrome と技術的に無関係であるため、誤解を避けるため不採用としました。 -
通常の開発では到達不可能な、次のリリースバージョンに近い値にする (例: 開発中: 0.12.99 → リリース: 0.13.0)
理由: 一部のソフトウェアでは、大きなバージョンアップを予告するために使用されますが、 開発に関わっていないと意味やニュアンスが伝わりにくい可能性があるため、不採用としました。 -
dev
理由: タグを辞書順に並べたとき alpha の a や beta の b より dev の d の方が後ろになります。 パッケージングツールによってはバージョンが巻き戻っているように判断される場合があるため、 パッケージのバージョンを独自の形式にする必要があります。 JDimが表示するバージョンとパッケージのバージョンが異なると分かりにくくなるため、不採用としました。 (Thanks to @mtasaka.)
未解決の問題を書きます。
- 現行リリースのバグ修正版をリリースする必要が生じた際はどうするか
バグ修正版が必要になった場合は、改めてissueを作成し議論します。