重要なバグを修正する際のセマンティックバージョニング

私は現在、多くのパブリックな用途があるライブラリを管理しており、セマンティックバージョン管理について質問がありました。正しく実装されていないライブラリのかなり重要な部分をリファクタリングしたい-そして常に正しく実装されていない。ただし、これを行うと、パブリックAPIが変更されることになり、これは大きな決断です。

私が行いたい変更は、イテレータの使用方法を中心に展開します。現在、ユーザーはこれを行う必要があります。

while ($element = $iterator->next()) {
   // ...
}

少なくともPHPのネイティブIteratorインターフェイスでは、これは正しくありません。これに置き換えたい：

while ($iterator->valid()) {
   $element = $iterator->current();
   // ...
   $iterator->next();
}

これは次のようなものです：

foreach ($iterator as $element) {
    // ...
}

トムのセマンティックバージョニングのガイドを見ると、パブリックAPIへの変更（つまり、下位互換性のないもの）はメジャーリリースを正当化すべきであると明確に述べています。したがって、ライブラリは1.7.3から2.0.0にジャンプしますが、これは私にとってはあまりにも大きな一歩です。修正される機能は1つだけです。

最終的に2.0.0をリリースする計画はありますが、ライブラリを完全に書き直し、多数のパブリックAPIの変更を実装したときだと思いました。このリファクタリングの導入は、メジャーバージョンリリースを保証しますか？私は本当にそれがどのように見えるかわかりません-私は1.8.0または1.7.4としてそれをリリースすることをより快適に感じます。誰かアドバイスがありますか？

セマンティックバージョニングを作成したくないため、「バージョニングをサポートする広告」を作成したいので、ためらいます。バージョン番号「2.0」は、APIを変更したのではなく、ライブラリに新しいクールな機能がたくさんあることを世界に知らせるものです。大丈夫です（多くのソフトウェア会社や開発者がそうしています）。私見には、次のオプションがあります。

• セマンティックバージョニングに固執し、バージョン番号を2.0.0に変更する必要があるという事実に耐えます
• バージョン管理スキームを4つの数字に変更します。「1.1.7.3」が現在のバージョンであり、「1.2.0.0」がAPIの変更後の次のバージョン、「2.0.0.0」が「完全に新しい2.x製品ファミリー」の最初のバージョンです。
• 修正に下位互換性を持たせます（したがって、の機能を変更せずnextに、validおよびcurrent関数を追加するだけです）。その後、次のバージョン番号として「1.8.0」を使用できます。の動作を変更することnextが本当に重要だと思う場合は、2.0.0で変更してください。

セマンティックバージョニングのトムのガイドに固執します。

パブリックAPIへの大幅な変更は、次の2つのポイントのいずれかで行う必要があります。

1. 決して
2. メジャーリリースアップデートで

ところで、私の投票は最初のものです。しかし、私はそれが些細なことだけに適していることを認めます。

問題は、後方互換性を維持し、APIの以前のユーザーに支障をきたさないようにすることです。

本質的に、変更を知らないユーザーのためにインデックス作成エラーを作成しています。このような変更を強制すると、すべてのユーザーが次のことを強制されます。

1. 新しいアプローチを使用するように修正をコーディングする
2. 修正を検証し、それが何も壊さないことを確認します
3. 製品の新しいリリースをエンドユーザーに出荷する

特に、このような変更を検証するためにテストケースを配置しているプロジェクトが少ないことを考慮すると、多くの労力がかかる可能性があります。また、インストールを更新する必要があるユーザーからのダウンストリームユーザーの数を考慮すると、作業量が複雑になります。

これほど小さいものについては、気にせずに手放します。
それが本当にあなたを悩ませている場合（明らかにそうするか、あなたが尋ねなかったでしょう）、私は次のことをします。

1. コードツリーにv2.0.0ブランチを作成します
2. この変更であるv2.0.0ブランチへの最初の貢献をします
3. Release Notes変更が近づいていることを放送する前にプレビューを送信する

そして、バージョン番号を新しいメジャーリリースにアップグレードすることを正当化する他のものを蓄積するのに時間がかかるので、しばらくお待ちください。高度な通知（パート3）を使用すると、エンドユーザーからフィードバックを受信して​​、変更がどの程度の影響を与えるかを知ることができます。

別の解決策は、希望する方法で動作する新しい関数を追加することです。

その場合、修正を提供するためにfoo()作成fooCorrect()しますが、後方互換性も完全に保持します。そして、ある時点でfoo()、使用しないことを他の人に知らせるために非推奨にすることができます。

そこでの課題は、更新が必要な他の何かを見つけることでfooCorrect()あり、最終的にはfooCorrectedCorrect()か、他のいくつかの愚かなナンセンス。

本当に欲しいなら今すぐ修正しは、この代替アプローチがおそらく最善の方法です。APIの操作が難しくなるため、この方法で多くの追加関数を作成することに注意し、注意してください。そして、その認識は、これらのタイプの最悪の問題を防ぐのに十分かもしれません。

しかし、これは小さな何かを考慮するための「最も悪い」アプローチかもしれません。