Nablarch のバージョンアップ方針¶
Nablarchが提供する コンテンツに対するバージョンアップ方針について説明します。
リリース単位¶
Nablarchはバージョン単位でリリースします。 バージョンは、複数モジュールの組み合わせで構成されます。
| モジュール例 | Nablarch6 | Nablarch6u1 | Nablarch6u2 |
|---|---|---|---|
| nablarch-fw | 2.0.0 | 2.0.1 | 2.0.2 |
| nablarch-common-dao | 2.0.0 | 2.1.0 | 2.1.0 |
| nablarch-fw-jaxrs | － | － | 2.0.0 |
上記表のうち、6/6u1/6u2がNablarchのリリースバージョンになります。
バージョンアップの種類¶
Nablarchのバージョンアップは3種類あります。
| 種類 | 説明 | 更新対象コンテンツ | リリースサイクル |
|---|---|---|---|
| マイナーバージョンアップ | アプリケーションフレームワークに対する大規模な機能追加・変更を伴う機能変更を行います。 例） ・実行制御基盤の刷新 |
アプリケーションフレームワーク 開発ツール 開発標準 |
１年～ |
| リビジョンアップ | 不具合対応、機能追加・変更を行います。
例） ・Java最新版対応 ・開発標準の追加/変更 |
同上 | 半期 [1] |
| バグフィックス | セキュリティ・運用レベルに致命的な影響を与える、緊急性が高いアプリケーションフレームワークの不具合に対応します。 | アプリケーションフレームワーク | 随時 [2] |
| [1] | 不具合については、影響範囲を見定めリリーススケジュールを決定し、リリースします。 |
| [2] | 不具合検出後直ちに対応します。 |
バージョンの番号体系¶
バージョンの番号体系は、下記のとおりです。
(プロダクトバージョン番号)u(アップデート番号)
- 例）
- プロダクトバージョン番号
- マイナーバージョンアップ時にインクリメントされます。
例）Nablarch 6u6 → Nablarch 7
開始番号は5です。- アップデート番号
- リビジョンアップまたはバグフィックス時にインクリメントされます。
例）Nablarch 6u6 → Nablarch 6u7
開始番号は0です。ただし、番号0の場合はアップデート番号は付けられません。
後方互換性ポリシー¶
Nablarchの後方互換性ポリシーについて説明します。
後方互換性を維持する範囲¶
アプリケーションフレームワークとテスティングフレームワーク（以下「フレームワーク」）のバージョンアップは、 後方互換性の例外 に該当する場合を除き、 後方互換性維持の内容 に記載の内容で、後方互換性を維持します。
重要
この後方互換性ポリシーは、フレームワークのAPIのうち、Nablarchが定める公開APIを対象にしています。 Nablarchが定める公開APIは、 Published アノテーションが付与されたAPIになります。 クラスの全APIを公開する場合はクラス宣言に、 個別にメソッドを公開する場合はメソッド宣言に Published アノテーションを付与しています。 Published アノテーションが付与されていないAPIは、非公開APIになります。
非公開APIは、後方互換性が維持されないバージョンアップを行う場合がありますので、プロジェクトにて非公開APIを使用しないでください。 プロジェクトにて非公開APIを使用した場合、バージョンアップ時に後方互換性が維持されず、思わぬ不具合が発生する可能性があります。
なお、アダプタについては外部ライブラリを使用するために用意しているコンポーネントであり、ここで言うフレームワークには含まれません。 ですが、利用者が使用することを想定したアダプタのAPIにはPublishedアノテーションを付与しています。 アダプタは外部ライブラリのAPIに依存しているため、バージョンアップの際に外部ライブラリの破壊的変更に伴ってどうしても後方互換性を維持できない場合があります。 後方互換性を維持できるように努めますが、そうした理由から後方互換性ポリシーの対象外となります。 Publishedアノテーションを付与していないアダプタのAPIについては非公開APIと同様に使用しないでください。
Nablarchでは、非公開APIの使用を検知するツールを提供しています。 プロジェクトにてこのツールを使用して非公開APIが使用されないように運用してください。 ツールの詳細は、 許可していないAPIが使用されていないかチェックする を参照してください。
補足
Publishedアノテーションを付与する際は、アーキテクト向けとアプリケーションプログラマ向けに分類しています。
- アーキテクト向けの公開API → @Published(tag = “architect”)
- アプリケーションプログラマ向けの公開API → @Published
どちらも公開APIであり、後方互換性が維持されるため、プロジェクト判断でアーキテクト向けの公開APIを アプリケーションプログラマ向けに公開しても問題ありません。
補足
フレームワーク以外のコンテンツは後方互換性の維持の対象外です。
例えば、ドキュメントの後方互換性を維持するとはどういうことでしょうか。 旧バージョンのフレームワークを用いた場合の記述を残しておくことでしょうか。 しかし、それは旧バージョンのドキュメントを見れば済むことです。開発標準にも同じことが言えます。 Nablarch ツールも、旧バージョンの設計書を用いているのであれば、そのバージョンの開発ツールを使用すればすみます。 また、お客様独自のカスタマイズがなされているかもしれません。 この場合は後方互換性が保たれていたとしても、やはり独自のカスタマイズを行うことに変わりはありません。
このように、フレームワーク以外のコンテンツについては、その必要がないので、後方互換性の維持の対象外としています。
後方互換性維持の内容¶
Nablarchは、Nablarch自身のバージョンアップの際に発生する作業が可能な限り少なくなるよう、 後方互換性を考慮したバージョンアップを行います。
この後方互換性ポリシーは以下のとおりです。 フレームワークのバージョンアップを行った場合に、できる限り下記を発生させないよう考慮します。
- 既存のアプリケーションコードの修正。
- 既存の自動テストコードの修正。
- 既存の自動テストデータの修正。
この後方互換性維持の方針により フレームワークは、基本的に、 使用するNablarchのバージョン の差し替えと設定ファイルの変更のみでバージョンアップできます。