Rubyエコシステム内（または他の場所でも）にSemVerに代わる機能する（つまり、bundlerand で使用できる）ものはありますか？rubygems

SemVer ( MAJOR.MINOR.PATCH ) に関する私の問題は、2 つの互換性のないものを定量化しようとすることです。

1. サイズの変更 (パッチ-- 小さな変更)
2. 下位互換性 (マイナー-- 非互換、メジャー-- 互換性なし)

ただし、 PATCHは依然として互換性を破る変更である可能性が非常に高く、これにより、MINORよりも小さい一方でMAJORと同等になり、MINORはMAJORよりも小さくなります。それで：

これは、同時に PATCH <> MINOR であることを意味しますが、これは決して真ではありません。

理想的には、2 つのバージョニング ラインを作成したいと考えています。1 つは下位互換性に基づいており (たとえば、壊れていない、潜在的に知覚できない破損 (==パッチ)、壊れている)、もう 1 つは変更サイズに基づいています (下位互換性は無視)。もしそうなら、バージョン管理行。そして、それらを同時に使用できるようにしたいと思います。

(純粋な下位互換性ベースのバージョン管理だけで、「hello world」を画面に表示してオペレーティング システムが起動する限り、「hello world」からオペレーティング システムに移行できます。)

例: Hが人間に優しいバージョン管理を表し、Bが下位互換性に基づく下位互換性を表す場合、次のように言えます。

1. ~> H2.0 (== H2.X に固執します。200MB の非破壊的な追加機能を追加するバージョン H3.0 を作成する場合、それをダウンロードしてほしくありませんが、あなたが行った非破壊的な改善を私にもたらしてくださいH2.0ライン）
2. ~> B0.1 (==互換性を損なわない変更(3 列目、Semver の 2 列目と同等) と潜在的に破壊的な 変更 (2 列目、SemVer の 3 列目と同等) を教えてください)

免責事項

私たちのチームは約 2 年間、職場のプロジェクトで git を使用してきましたが、他のプロジェクトをフォークしたことは一度もないので、貢献する部分ではかなり新しいものです。

私たちの状況

リポジトリをフォークして、それを独自のプロジェクトの出発点として使用したいと考えています。まず、コードの一部を自分たちのニーズに合わせて変更したいと考えていますが、有用なものを思いついた場合は、元のプロジェクトにも貢献したいと考えています。

問題

私たちが直面している問題は、プロジェクトにセマンティック バージョニングを使用して から開始したいということですがv1.0.0、元のリポジトリもセマンティック バージョニングを使用しているため、v1.0.0タグが既に存在します。

元のプロジェクトに貢献する能力を失うことなく、元のリポジトリの次に独自のセマンティック バージョニングを維持する方法はありますか? それとも、この貢献が完全に間違っているのでしょうか?別の方法で行うべきでしょうか?

私は現在、Composerを介して多くの依存関係を持つ PHP 駆動の Web サイトに取り組んでいます。

最近、依存関係に ( SemVerによる) マイナー バージョンの変更があり、下位互換性を壊す変更が含まれていました。ウェブサイトが予期せず壊れました。依存関係のバージョン番号をより正確なものに更新しまし1.2.16た1.*。

ただし、マイナー バージョンは頻繁に変更されるため、バージョンの追跡が難しくなります。

依存関係を簡単に追跡し、変更を壊してプロジェクトを壊さないようにするにはどうすればよいでしょうか?

(semver を使用して) 以前にリリースされたバージョン/タグにパッチまたはマイナー アップデートを適用するための gitflow プロセス/フローは何ですか?

例えば：

ソフトウェアのマスター/メイン ブランチには、v2.0.0 の最新のタグ/バージョンがあります。ただし、v1.0.1 でソフトウェアの v1 の最新の更新を行う必要があるバージョン v1.0.0 にパッチ/マイナー アップデートを適用する必要があります。パッチ/マイナー アップデートは、マスター v0.2.1 で最新のタグを作成する v2.0.0 にも適用する必要があります。