Nablarch のバージョンアップ方針

Nablarchが提供する コンテンツに対するバージョンアップ方針について説明します。

リリース単位

Nablarchはバージョン単位でリリースします。 バージョンは、複数モジュールの組み合わせで構成されます。

Nablarchのリリース単位
モジュール例 Nablarch5 Nablarch5u1 Nablarch5u2
nablarch-fw 1.0.0 1.0.1 1.0.2
nablarch-common-dao 1.0.0 1.1.0 1.1.0
nablarch-fw-jaxrs 1.0.0

上記表のうち、5/5u1/5u2がNablarchのリリースバージョンになります。

バージョンアップの種類

Nablarchのバージョンアップは3種類あります。

バージョンアップの種類
種類 説明 更新対象コンテンツ リリースサイクル
マイナーバージョンアップ アプリケーションフレームワークに対する大規模な機能追加・変更を伴う機能変更を行います。

例)
・実行制御基盤の刷新
アプリケーションフレームワーク
拡張コンポーネント
開発ツール
開発標準
実装例集
1年~
リビジョンアップ 不具合対応、機能追加・変更を行います。
例)
・Java最新版対応
・開発標準の追加/変更
同上 半期 [1]
バグフィックス セキュリティ・運用レベルに致命的な影響を与える、緊急性が高いアプリケーションフレームワークの不具合に対応します。 アプリケーションフレームワーク 随時 [2]
[1]不具合については、影響範囲を見定めリリーススケジュールを決定し、リリースします。
[2]不具合検出後直ちに対応します。

バージョンの番号体系

バージョンの番号体系は、下記のとおりです。

(プロダクトバージョン番号)u(アップデート番号)
例)
5 : プロダクトバージョン5 初期リリース
5u1 : プロダクトバージョン5 アップデートリリース1
プロダクトバージョン番号
マイナーバージョンアップ時にインクリメントされます。
例)Nablarch 5u6 → Nablarch 6
開始番号は5です。
アップデート番号
リビジョンアップまたはバグフィックス時にインクリメントされます。
例)Nablarch 5u6 → Nablarch 5u7
開始番号は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のバージョン の差し替えと設定ファイルの変更のみでバージョンアップできます。

後方互換性の例外

下記内容に該当する場合は、後方互換性が維持されないバージョンアップを行う場合があります。

  • フレームワークが出力するログのレベル、文言に対する変更。
  • フレームワークの不具合が検出され、その対応が後方互換性を維持したまま実施できない場合。
  • フレームワークを動作させる環境である、JDKのバージョンアップに起因する問題が発生し、その対応が後方互換性を維持したまま実施できない場合。

なお、後方互換性が維持されない変更になる場合は リリースノート の「システムへの影響の可能性の内容と対処」列にその内容と移行方法を明記します。