私の会社は10年間システムを開発しています。このシステムには、ほぼ独立した 15 のサブシステムがあり (同じライブラリ、パッケージ、または DB を使用する場合があります)、これらのサブシステムは別々のチームでローカルに構築されています。また、サブシステムの構成を読み取り、メニューとサブメニューを含むページを構築するためのメインのシンプルなシステムが開発されています。構成から（ショートカット付き）。当社製品は、このメインシステムのexeです。
残念ながら、当社では標準のバージョン番号を使用していません。さて、社内に標準を強制することにしました。セマンティック バージョニングは満足のいく標準であることがわかりましたが、私たちの場合、いくつか質問があり ます。多くの場合、サブシステムに大幅な変更を加えた後でも、メイン システムのコードは影響を受けません。メインシステムの変更はそのシステムのバージョン番号を形作るべきだと思いますが、この場合は意味がありません. 複数のサブシステムで構成される大規模なアプリケーションをバージョン管理するためのソリューションはありますか?
MAJOR.MINOR.PATCH へのリンクを提供し、
互換性のない API の変更を行う場合は MAJOR バージョンをインクリメント
し、下位互換性のある方法で機能を追加する場合は MINOR バージョンをインクリメントし、下位
互換性のあるバグ修正を行う場合は PATCH バージョンをインクリメントします
。サブシステムは、メイン システムを非互換にする可能性があります: 追跡することが多すぎます。
各サブシステムは独自のバージョンを使用する必要があります。メインシステムでは、依存関係と独自のバージョン管理の概要が必要です。
これはさまざまな方法で管理できます。1 つの方法は、Maven および pom.xml ファイルを使用することです。別の方法は、異なるバージョンの構成ファイルを使用することです。
各チームは、独立した独自のコードを開発し、セマンティック バージョンを割り当てることができます。
いつの日か、共有ライブラリ、パッケージ、および DB をリポジトリに配置し、すべてのチームが独自の pom.xml でそれらを参照できるようになるでしょう。
あなたはこのように柔軟です。2 つ目のメイン システムを作成して (トップ クライアントまたは無料アカウント用に)、サブシステムを含む/除外する pom.xml を変更することもできます。2 番目のメイン システムには、独自のバージョン管理があります。
SemVer FAQ から:
パブリック API を変更せずに自分の依存関係を更新する場合はどうすればよいですか?
パブリック API には影響しないため、これは互換性があると見なされます。パッケージと同じ依存関係に明示的に依存するソフトウェアには、独自の依存関係仕様が必要であり、作成者は競合に気付くでしょう。変更がパッチ レベルであるかマイナー レベルの変更であるかの判断は、バグを修正するため、または新しい機能を導入するために依存関係を更新したかどうかによって異なります。私は通常、後者のインスタンスに追加のコードを期待しますが、その場合は明らかにマイナー レベルのインクリメントです。
これをあなたのシナリオに適用すると、次のようになります。メイン アプリケーション自体に大きな変更を加えることなく、依存するサブシステムをアップグレードする場合は、マイナー バージョンまたはパッチ バージョンのいずれかを増やす必要があります。独自のパブリック API は引き続き互換性があると見なされるため、メジャー バージョンをインクリメントする必要はありません。
メイン アプリケーションがサブシステムに追加された新機能を利用する場合、それはマイナー バージョンの増加である必要があります。
それ以外の場合は、パッチ バージョンの増加のはずです。