Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ClaudiaHeart

バージョン表記SemVerとCalVerについて

Posted at

iOSが2025年から年ベースのバージョン表記に変更

2025年、Apple は iOS / iPadOS / macOS / watchOS / tvOS / visionOS のバージョン番号を「26」のようにリリース年（シーズン）に紐づく方式へと統一しました。
従来の連番（18, 19…）から、年ベースの CalVer（Calendar Versioning）の一種に舵を切った格好です。

「26」は 2025年秋〜2026年にかけてのリリースサイクルを示す番号として、一目で解釈できるようになります。
個人的にバージョン表記についても興味があったので、これを機に調べてみました。

本記事は生成AIに下調べと下書きをしてもらったのち、加筆修正しました。

Semantic Versioning（SemVer）について

SemVerの基本

  • 形式: MAJOR.MINOR.PATCH
  • ルールの要点:
    • MAJOR: 後方互換性を壊す変更（破壊的変更）が入ったときに +1
    • MINOR: 後方互換性を保った機能追加で +1
    • PATCH: 後方互換性を保ったバグ修正・微修正で +1
  • 目的: 互換性の程度を番号から即座に読み取れるようにし、依存関係の安全な自動更新を支援すること

MODIFIER: 「dev」「alpha」「beta」「rc1」などのオプションのテキストタグを付与するケースもある。（例: 1.2.3-alpha）

SemVerを採用している代表的なソフトウェア／プロジェクト

  • npm / Node.js エコシステム（package.json の依存範囲 ^, ~ など）
  • NuGet（.NET）（SemVer 2.0.0 サポート）
  • Go Modules（v2+ ではモジュールパス末尾に /v2 等を要求）
  • Rust / Cargo（デフォルトの “caret 要件” で SemVer 互換更新を自動許容）
  • Kubernetes（リリースは x.y.z の SemVer に準拠）

ほかにも、数多くの OSS ライブラリ／SDK／CLI が SemVer を前提にエコシステムを構築しています。

SemVerのメリットデメリット

メリット

  • 互換性が数字で明確: 破壊的変更の有無が MAJOR の差分で把握可能
  • 依存管理ツールと相性が良い: 範囲指定と自動アップデートがしやすい
  • 変更の大きさが伝わる: PATCH / MINOR / MAJOR で心理的負担を調整

デメリット

  • "何が破壊的変更か"の判断が難しい: 実運用で線引きがぶれやすい
  • リリースが頻繁になると煩雑になりがち: 体系的なリリース運用や自動化が必須
  • 鮮度が分かりにくい: バージョンからリリース時期を直感できない

リリースブロック

リリース周りを考えると確かにデメリットがポロポロ出てきそう。

Witness the version, racing to numeric motionlessness.

セマンティック バージョニング 2.0.0 | Semantic Versioning

1.0.0のリリースはいつすべきでしょうか？
　もし既にプロダクション用途であなたのソフトウェアが利用されているのなら、それは1.0.0であるべきでしょう。
　またもし安定したAPIを持ち、それに依存しているユーザーが複数いるのなら、それは1.0.0であるべきでしょう。
　もし後方互換性について多大な心配をしているのなら、それは1.0.0であるべきでしょう。

一生1.0.0にならない、ありがちなやつですね。
誰にとって何が破壊的な変更になるのか判断するのは難しいし、安定性や後方互換性を考えると心理的にメジャーアップデートに決め辛いところはあるかも。

破壊的変更の代表例

Python 2 → 3

Python 3 では テキスト（Unicode）とバイナリ（bytes）を厳密に分離し、print は文から関数へ、整数除算の挙動も変更されました。代表的な影響は次の通りです。

  • print 構文 → print() 関数
  • 文字列型の整理: str（テキスト, Unicode）と bytes（バイナリ）
  • 除算演算子 / のデフォルトが実数除算に（// が切り捨て）
  • range() がイテレータ化、dict.keys() などの戻り値もビューへ
  • 標準ライブラリの再編（例: urllib 系の配置・名称変更）

大規模コードでは 2to3 などの移行ツールや段階的な互換レイヤの整備が定石でした。

Java 8 → 9

Java 9 では JPMS（モジュールシステム）が導入され、JDK の内部 API が強くカプセル化されました。
これにより、sun.*/com.sun.* など内部 API への反射アクセスや分割パッケージ等が問題になりました。

  • 強カプセル化（のちに JDK 17 でより厳格化）により、内部 API への反射アクセスが警告→原則不可へ
  • rt.jar など JRE/JDK のファイル構成が変更、モジュール化（jlink 等）
  • クラスパスとモジュールパスの併存、自動モジュールや分割パッケージの落とし穴

実務では --add-opens などの移行フラグで一時吸収しつつ、ライブラリ更新や実装置き換えを段階的に行うのが現実解でした。

Calendar Versioning（CalVer）について

CalVerの基本

  • 形式の例: YYYY.MM.PATCH / YY.MM / YYYY.MINOR など（プロジェクトごとに流儀あり）
  • 目的: 「いつの版か」を伝えることに特化しており、定期リリースやロングタームの保守戦略と相性が良い。

CalVerを採用している代表的なソフトウェア・プロジェクト

  • Ubuntu（YY.MM 例: 24.04, 24.10）
  • JetBrains IDEs（IntelliJ など）（例: 2024.1, 2024.2）
  • Unity（例: 2022.3 LTS）
  • Home Assistant（例: 2025.3.5 のように年・月を含む）
  • CockroachDB（例: 24.2 など四半期ベースの年次表記）
  • （2025年〜）Apple 各OS（例: iOS 26 / macOS 26 など、年次シーズンを示す統一番号）

さらに NixOS / Arch（ISO 名称）/ Android Studio / systemd / pip など、多くのプロジェクトが CalVer 系の表記を採用しています。

CalVerのメリットデメリット

メリット

  • 鮮度とサポート期間が直感的: 年・月からリリース時期が分かる
  • 定期リリース運用と相性が良い: 毎月/四半期の最新版というメッセージが伝わる
  • プロダクトマネジメントが楽になる場合も: 変更の重さよりリリースの頻度やサイクルで刻める

デメリット

  • 互換性の重さが番号から読めない: 破壊的変更の有無は別途リリースノート等で確認が必要
  • SemVerを採用しているツールと衝突: 範囲指定やソートなどでブレが出るかも
  • 軽微な変更でも番号が大きく見える: 番号を見ただけでは更新判断がしづらい

リリースサイクル

日付ベースのバージョン管理になるので、リリーススケジュールがある程度決まっている場合は、リリースサイクルを決めやすい。
CalVerに限った話ではないですが、リリースサイクルが決まっているならフィーチャートグルを導入していると、リリーススケジュールに合わせた開発がしやすくなりそう。

どう使い分けるべきか

プロジェクト種別 SemVer を選ぶと良い場合 CalVer を選ぶと良い場合
ライブラリ／SDK／API 外部依存が多く、互換性保証を数字に載せたい。
CI/CD で 安全な自動更新を回したい。		 年次での サポート窓口の明確化を最優先したい場合。
ただし 破壊的変更の明示はドキュメントで補完必須。
アプリ／SaaS／OS プラグインや外部連携が多く、互換性インパクトが大きい。 定期リリースや LTS 戦略をユーザーに伝えたい。
“新しさ”重視のアップデート文化を作りたい。
巨大エコシステム 依存グラフが複雑で、機械的な判断が必要（例: K8s, npm, NuGet, Go, Cargo）。 ディストリや IDE のように 時期で追いかける文化が根付いている。

使い分けの判断をざっくりと決めるなら、利用者が開発者であればSemVerで、利用者がユーザーであればCalVerといった具合でしょうか。
アプリなのか、OSなのか、ソフトウェアの性質にもよりますが。

まとめ

  • SemVer は 互換性の意味を番号で伝えるのが得意で、ライブラリや API など、他者が依存する成果物で威力を発揮する
  • CalVer は いつの版かを伝えるのが得意で、定期リリース／LTS／SaaSで運用が分かりやすい

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?