Jiemamyのバージョン番号付与ポリシーを解説します。

目次

概要

X.Y.Z形式の、Xを「メジャー番号」、Yを「マイナー番号」、Zを「リリース番号」と定義します。

ただし、基本的にこのポリシーでバージョニングを行いますが、v1.0以前のリリースに対しては厳格に対応しません。なるべく従いますが。これは互換性に関する制約をきつくすると初期段階の開発を著しく妨げることが理由となっています。

基本的に、X.Y が仕様バージョン番号を表し、Zが各コンポーネントのリリース通番を表します。したがって、X, Yは各コンポーネント間で関連(同じ仕様に準拠している)がありますが、Zはコンポーネントごとにリリースされた連番を割り当てられるだけなので、番号の一致に意味はありません。

基本

バージョンは、X.Y.Z 形式で付与します。

X, Yは、このリリースが準拠するJiemamy specsのバージョンを表します。Zは準拠仕様は変わらず、実装バグの修正などが行われた場合や、仕様の範囲内で新しい機能が追加された際に繰り上げます。準拠する仕様バージョンが変わった際には、Zは0にリセットされます。

例外1 ― Jiemamy specs (zeus)

バージョンは X.Y 形式で付与します。仕様コンポーネントには、基本的に実装は含まれていないため、Zにあたる番号はありません。「このコンポーネントの何かが変わる事」は、「仕様変更」を意味し、完全な互換性を維持することはできません。

仕様改善や仕様バグの修正などで仕様が変更になった際に、マイナー番号を繰り上げます。マイナーバージョンアップは仕様変更が含まれますが、過去のAPIはdeprecatedになるだけで、以前のバージョンと互換性を保ち、使用可能な状態を維持しています。

大幅な仕様変更が加わった時など、互換性を維持することができないバージョンアップの際に、メジャー番号を繰り上げます。この場合、今までdeprecatedであったAPIは完全に廃止される可能性があります。また、deprecatedでなかったAPIに関しても、仕様が変更となる可能性があります。

例外2 ― Jiemamy vesta (Eclipse関連)

バージョンは X.Y.Z.qualifier 形式で付与します。

X, Y, Z については基本と"同様"です。qualifierは、パッケージ作成のタイムスタンプを元に yyyyMMddHHmmss 形式で生成されます。(例: 200912311455) これは、Eclipseプラグインの慣習に従ったもので、リリース時期が明確になる以外の意図はありません。