セマンティックバージョニング
ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。
セマンティックバージョニング は、リリース可能なソフトウェアコンポーネントに導入されたAPI変更のタイプに基づいてバージョン番号をインクリメントする3層バージョン管理システムです。 これは、依存するコンシューマーとAPI実装のパッケージまたはモジュールのプログラム的な互換性を伝える標準的な方法です。 パッケージがプログラム的に（つまり、意味的に）プロジェクトと互換性がない場合、 Bnd （モジュールのビルド時に使用）はそのプロジェクトのビルドに直ちに失敗します。
セマンティックバージョンの形式は次のようになります。
MAJOR.MINOR.MICRO
特定のイベントにより、各層が強制的に増分されます。
- MAJOR： 互換性のない、APIに違反する変更が行われた
- マイナー： APIのプロバイダーのみに影響する変更、または新しい下位互換機能が追加されます
- MICRO： 後方互換性のあるバグ修正が行われます
セマンティックバージョニングの詳細については、公式の セマンティックバージョニング サイトおよび OSGi Allianceのセマンティックバージョニング テクニカルホワイトペーパーを参照してください。
Liferay DXPのモジュールはすべて、セマンティックバージョニングを使用しています。
Liferay DXPは何百もの独立したOSGiモジュールを含むモジュラープラットフォームであるため、セマンティックバージョニングに従うことが特に重要です。 多くの依存関係を含む独立したモジュールが多数あるため、新しいパッケージバージョンをリリースするとすぐに恐ろしくなります。 この複雑に絡み合った依存関係のシステムでは、プロジェクトのAPIバージョンを細心の注意を払って管理し、それを利用する人との互換性を確保する必要があります。 Semantic Versioningの簡単なシステムとLiferayツールの助けを借りて、プロジェクトのバージョンを簡単に管理できます。
プロジェクトのベースライン化
セマンティックバージョニングを手動で実行することは、一見簡単に思えます。 善意の開発者がプロジェクトのセマンティックバージョンを手動で更新するという悲しい歴史があります。 真実は、単純な更新の影響を予測するのは難しいことです。 これを回避するには、次のことが可能 ベースライン プロジェクト、それが更新された後。 ベースライン化は、セマンティックバージョニングルールがプロジェクトに従っていることを確認します。 これにより、人間にとってそれほど明白ではない多くの明らかなAPIの変更をキャッチできます。 ただし、このツールはJavaクラスまたはインターフェースのシグネチャ、またはAPI use 変更（メソッドに関する仮定など）で表されない互換性の変更を識別するほどスマートではないため、あらゆる種類のコード変更を行うときは常に注意する必要があります呼び出し順序、または入力および/または出力エンコーディングの変更）。 ベースラインは、その名前が示すとおり、互換性の問題の大きなクラスがあなたをすり抜けないという ベースライン 快適さの一定の尺度を提供します。
LiferayのBaseline Gradleプラグインを使用して、ベースライン機能を提供できます。 Gradleビルド構成に追加し、次のコマンドを実行します。
./gradlew baseline
設定の詳細については、 Baseline Gradle Plugin 記事を参照してください。 このプラグインは、デフォルトで Liferay Workspace では提供されていません。
baseline コマンドを実行すると、プラグインは最新のリリースされた非スナップショットモジュール（ベースライン）に対して新しいモジュールをベースライン化します。 つまり、新しいモジュールのパブリックエクスポートされたAPIをベースラインと比較します。 変更がある場合、OSGiセマンティックバージョニングルールを使用して、最小の新しいバージョンを計算します。 新しいモジュールのバージョンが古い場合、エラーがスローされます。
ベースラインを使用すると、プロジェクトのセマンティックバージョニングは、APIが表現するのと同じくらい正確です。
アーティファクトと依存関係のバージョンの管理
Semantic Versioningでプロジェクトのアーティファクトと依存関係のバージョンを追跡するには、2つの方法があります。
- バージョンの範囲
- 正確なバージョン（1対1）
Liferay DXPの複数のバージョンのプロジェクトをビルドし、最大限の互換性を維持する場合は、さまざまなバージョンを追跡する必要があります。 つまり、アプリのパッケージの複数のバージョンが機能する場合、それらのいずれかを使用するようにアプリを構成できます。 さらに、Bndは、モジュールが依存する各パッケージの意味的に互換性のある範囲を自動的に決定し、範囲をモジュールのマニフェストに記録します。
バージョン範囲の構文のヘルプについては、 OSGi仕様参照してください。
OSGiバンドルの bnd.bnd にインポートされたパッケージのバージョン範囲は次のようになります。
Import-Package: com.liferay.docs.test; version="[1.0.0,2.0.0)"
一般的なビルドツールもこの構文に従います。 Gradleでは、依存関係のバージョン範囲は次のようになります。
compile group: "com.liferay.portal", name: "com.liferay.portal.test", version: "[1.0.0,2.0.0)"
Mavenでは、次のようになります。
<groupId>com.liferay.portal</groupId>
<artifactId>com.liferay.portal.test</artifactId>
<version>[1.0.0,2.0.0)</version>
最新リリースバージョンの指定は、上限のないバージョンの範囲と見なすこともできます。 たとえば、Gradleでは、 バージョンとして指定されてい<code> ： "latest.release"。 これは、バージョンマーカー RELEASE使用してMaven 2.xで実行できます。 Maven 3.xを使用している場合、これは不可能です。詳細については、 Gradle および Mavenのそれぞれのドキュメントを参照してください。
さまざまなバージョンの追跡には料金がかかります。 問題をデバッグしているときに古いビルドを再現するのは困難です。 また、使用するバージョンに応じて異なる動作のリスクも伴います。 また、最新のリリースに依存すると、大きな変更が導入された場合にプロジェクトとの互換性が失われる可能性があります。 バージョンの範囲を指定する場合は注意して進め、含まれているすべてのバージョンでプロジェクトがテストされていることを確認する必要があります。
依存関係の正確なバージョンを追跡する方がはるかに安全ですが、柔軟性が低くなります。 これにより、特定のバージョンの@ <product@>制限される場合があります。 また、その特定のバージョンにのみ存在するAPIにロックされます。 これにより、モジュールのテストがはるかに簡単になり、予期しないエラーが発生する可能性が低くなります。
これで、依存関係を範囲および完全一致として追跡することの長所と短所がわかりました。