rubygems/bundler では、2 つの異なる並行バージョン番号を持つことはサポートされていません。
しかし、semver を使用しなければならない理由はありません。必要なバージョン番号は 1 つだけです。Bundler と rubygems は、すべてのコンポーネントが数字である「xyz」、または「xy」または「xyzab」の形式のバージョン番号で問題なく動作します。「機能する」限り、1 つのバージョン番号で、やりたいことが何でもできます。(数字だけでなく文字を使用すると、rubygems はそれが「プレリリース」バージョンを示していると判断する可能性があります。しかし、数字に固執する場合は、好きなことを行うことができます)。
semver 以前は、多くの人は、大きな変更、小さな変更、または小さな変更のように「思われた」ときに、そのように感じたときにコンポーネントをインクリメントしていました。確かにそれを行うことができます-または、適用する単一のバージョン番号を決定するために他のシステムを使用します-インフラストラクチャは正常に機能します. 下流のユーザーはそれを評価するかもしれませんし、しないかもしれません。
ただし、semverを誤解しているかどうかはわかりません。Semver は、重大な変更はメジャー バージョンのインクリメントでなければならないと述べています。「ただし、PATCH は依然として重大な変更である可能性が高い」場合は、semver を行っていません。semver によると、重大な変更はメジャー バージョンの更新である必要があります。これは、偶発的なバグのため、またはsemverを理解していないか、それに従うことを望まないが、とにかくフォローしていると言いたい人のために、常に従うとは限りません-しかし、それはsemverが言うことです.
実際、semver は、バージョン番号は、変更の「サイズ」(主観的な「大きさ」であれバイトサイズであれ) ではなく、互換性に関するものであるべきだと言っています。あなたはバイトサイズのデルタについて話しているようですが、バージョンの解釈を見たことがありません。前の数字）。後方破壊的変更には、メジャー バージョンの更新が必要です。後方破壊的な変更のない新機能には、マイナー バージョン バンプが必要です。それ以外の場合 (新機能なし、後方破壊的な変更なし。つまり、基本的にバグ修正または内部リファクタリング) パッチ レベルのバンプ。センバーはしません2 つの互換性のないものを取り込もうとします。むしろ、そのうちの 1 つを完全に破棄しようとします。バージョン番号は「変更のサイズ」を表す必要があるという考えを破棄し、互換性を表すだけです。しかし、これに対する人々の抵抗は、semverに対する抵抗の一部です。
「いつの間にか変化を壊す可能性がある」とはどういう意味かわかりません。Semver は、破壊的変更はメジャー バージョン バンプであると述べています。それが「いつの間にか壊れる可能性がある」場合、それをパッチと呼ぶことはできません。Semver は、そのようなカテゴリには関心がありません。Semver では、パッチ レベル リリースで重大な変更をリリースすることは許可されていません。これは、それが「いつの間にか壊れる可能性がある」と判断したためです (それを望んでいるのでしょうか?)。
バージョン管理とリリース管理は大変です。多くの場合、メンテナの苦痛と下流のユーザーの苦痛のバランスです。2 つの別々の並行バージョン番号を作成することで、状況がさらに混乱するだけでなく、状況が改善されるかどうか、私は懐疑的です。「それをダウンロードしてほしくないが、H2.0 ラインで行った非破壊的な改善を私にもたらしてほしい」という実装方法も理解できません。2 つだけではないと想像しているようです。リリースごとにバージョン番号が表示されますが、実際にはバージョン番号のまったく異なる「行」が 2 つありますか?
2 つの異なる gem 名でリリースするだけでよいでしょう。Widget_H と Widget_B ですね。レポ内の 2 つの異なる git ブランチから離れていると思いますか? わかりません。あなたの思索がどのようにシステムに運用化される可能性があるのか を理解するのに苦労しています. メンテナーとダウンストリーム ユーザーの両方にとって、非常に混乱を招くように思えますが、2 つの異なる gem 名を使用するだけで、rubygems/bundler エコシステムで必要なことを実現できますか?
semverの仕様をまだ読んでいない場合は、読むことを強くお勧めします。そうすることで、semver とは何かを理解できます。