composer、satis、および SVN を使用して、社内の PHP ライブラリを管理しています。開発中に SVN トランクに変更をコミットし、テストの準備ができたらバージョンにタグを付けます (セマンティック バージョニングに従います)。ライブラリ バージョンがタグ付けされると、テスト環境への展開の一部として composer を使用できます。テストが成功したら、同じバージョンを本番環境にデプロイします。
ここでの問題は、テスト用にバージョンにタグを付けたら、次の製品リリースを準備するときに、新しくタグ付けされたバージョンが composer によって取得されるため、非常に注意する必要があることです。
私が想像しているのは、バージョンにベータ版または RC としてタグを付け (v1.1RC1 など)、RC またはベータ版を運用環境に展開することを拒否するように展開プロセスを何らかの形で構成することです。バージョンが正常にテストされた場合、そのバージョンをリリース済みバージョン (v1.1RC1 -> v1.1) として再タグ付けしてリリースします。
これは達成できますか？
あなたの言っていることから、新しいバージョンのライブラリにタグ付けすることを実際に恐れていることは理解できます。そのコードが実際に使用され、他のアプリケーションが壊れる可能性があるからです。
1 つのアプローチは、適切なテストを行うことです。ライブラリのバージョンにタグを付けることが問題になるとは思いません。テストがすべて緑色の場合、タグ付けしない理由はありません。これは、テストが基本的に「動作するかどうかを手動で確認する」だけの場合でも機能します。
2 番目のステップは、その新しいバージョンをアプリケーションに統合することです。実行composer updateして、アプリケーションがまだ実行されているかどうかを確認します。つまり、すべてのテストを開始して、緑色になるまで待ちます。
composer updateアプリケーションをチェックアウトし、最新のライブラリをすべて取得するために意図的に実行し、すべてのテストを実行し、a) 更新があり、b) それらが機能することを報告する別の領域を用意することをお勧めします。次に、開発者は更新を確認する必要があります。つまり、手動で再度実行して結果のcomposer.lockファイルをコミットするか、その更新テストから結果のロック ファイルを取得します。
非製品リリース バージョンを使用するメリットはないと思います。いずれにせよ、次のバージョンに対処する必要があります。最小の安定性設定を常に切り替えたり、ライブラリのバージョン要件にフラグを追加し@RCたり@betaしても、実際には役に立ちません。