パッケージの1つが複数のリリースをサポートする必要のあるアプリケーションである場合、monorepoでバージョンを管理する方法を理解しようとしています。
たった2つのパッケージ(lib
とapp
)のmonorepoがあるとします。
_repo:
- [email protected]
- [email protected] (depends on [email protected])
_
_[email protected]
_がリリースされました_release-app-1.0
_タグが作成されました。
コードの変更を続け、リポジトリは次のようになります。
_repo:
- [email protected]
- [email protected] (depends on [email protected])
_
これで、顧客は_[email protected]
_のコードに起因する_[email protected]
_のバグを発見しました。
このバグはどこで修正すればよいですか?
理想的には、lib
は現在_2.1
_にあるため、master
のバグを修正して_[email protected]
_を解放し、_[email protected]
_を更新して_[email protected]
_を使用する必要があります。
しかし実際には、いくつかの課題があります。
release-app-1.0
_を最初にチェックアウトして、_[email protected]
_がlib
に修正を実装できるかどうかを判断するために、SemVer互換のmaster
を使用していることを確認する必要があります。master
に変更を加えて_[email protected]
_を解放したら、それらすべての変更を_release-app-1.0
_にバックポートする必要がありますか(および方法)。 lib
から_release-app-1.0
_へのmaster
にのみ関連するすべての変更を選択することはほぼ不可能です。しかし、それを行わない場合、_[email protected]
_を解放してタグ_release-app-1.0.1
_を作成すると、app
とlib
の間のモノレポリンクが壊れます(_[email protected]
_は_[email protected]
_に依存します)。しかし、そのタグではlib
はまだ_2.0
_にあります)一方、_[email protected]
_を直接修正して_[email protected]
_をリリースした場合、SemVerを使用するメリットはなく、_[email protected]
_のすべての新機能/バグ修正を取得できます。
どんな提案も大歓迎です。ありがとう。
以前のバージョンに適用した修正を新しいバージョンで自動的に取得するこの問題の解決策はありません。
V2を修正してv2.0.1をリリースし、v2.1をリリース2.1.1を個別に修正する必要があります
ご存知のように、v2.1は内部的に完全にリファクタリングされています。 2.1を修正するために行ったコード変更は、2.1でもコンパイルされない可能性があります
チェリーピックは嘘です!
影響を受ける最初のリリースでバグを修正する必要があります。この場合はrelease-app-1.0
、lib
が2.0.1
にぶつかります。この修正はmaster
にマージまたはチェリーピックして、lib
を2.1.1
にバンプすることができます。
これは、他の人からアイデアを集めた後の私の考えです。
まず、monorepoの利点を説明しましょう。
package-a
:変更して公開package-b
:package-a
を更新、変更して公開package-c
:package-b
を更新、変更して公開この質問では、Googleなどの超大規模リポジトリについては説明しません。たとえば、小規模から大規模のモノレポに焦点を当てます。
唯一の違いは、以前のリリースをかなりの期間(1〜3年)サポートする必要があることです。
同じ例を使用してみましょう:
repo:
- [email protected]
- [email protected] (depends on [email protected])
[email protected]
をリリースする前は、基本的にはmaster
という1つのブランチしかありません。 [email protected]
、[email protected]
、[email protected]
のバージョンタグはすべてmaster
の下にあります。
開発を続けると、レポは次のようになります。
repo:
- [email protected]
- [email protected] (depends on [email protected])
ここで、[email protected]
および[email protected]
のバージョンタグはトレンドを継続し、すべてのものがmaster
の下で線形になり、次のようになります。
[email protected] ... [email protected] ... [email protected] ... [email protected] ... [email protected] (master, HEAD)
これでお客様の問題が発生します。 [email protected]
タグをチェックして、問題が[email protected]
内にあることを発見しました。これは[email protected]
です。これは、[email protected]
タグ以降、lib
にいくつかの変更が加えられる可能性があるためです(たとえば、日課の変更、バージョンバンプはトリガーされません)。
したがって、この時点で、2つのことを実行できます。
lib
の問題を修正し、[email protected]
として公開しますmaster
をチェックアウトし、そこでバグを修正して、[email protected]
として公開します(1)の利点は、それが単純で、変更が最小限であるため、強力なテストスイートがない場合でも、このアプローチを実行できることです。ただし、欠点は、最新のlib
に他のバグ修正がある場合、それらを取得できないことです(たとえば、新しいlib
は実際には[email protected]
)。
(2)を選択した場合、[email protected]
のlib
依存関係を[email protected]
に更新する必要があります("lib": "^2.1.1"
を明示的に指定するか、ロックファイルに依存して最新バージョン)。
その後、monorepoを使用して利益を得ることができるように、[email protected]
ブランチのlib
パッケージを何らかの方法で更新する場合に問題が発生します。
意見が本当に分かれるところがあります:
a)更新しない場合、プロセスは古いリリースと個別のサイロをすべて処理し、monorepoがもたらすすべての利点を無視します。
これは、リリースが短期間である場合、および/または開発の利便性よりもワークフローのシンプルさを重視する場合、合理的なアプローチです。
b)アップデートする場合は、次のプロセスに従います。
lib
コードを[email protected]
ブランチにチェリーピック(または直接コピー)して、コミットを実行します。lib
で必要な修正を実装し、コミット(およびオプションでバージョンをバンプしますが、タグは付けません)しますが、公開しません。lib
からmaster
に加えた変更を選択し、[email protected]
バージョンにタグを付けて公開します[email protected]
ステップ3と4を入れ替えて、ワークフローをより簡単にすることができます。これは、論理的推論のためにこのようにリストされています。
[email protected]
のバージョンタグは、[email protected]
ブランチの下ではなくmaster
で作成されるため、バージョンの追跡と履歴を維持しやすくなっています。