廃止されたメソッドを削除する前にどれくらい待つ必要がありますか？[閉まっている]

私はパブリックAPIを保守しており、メソッドを廃止する必要があります。

メソッドを廃止すべき削除前の月/年/バージョンの数に関する一般的なルールはありますか？

少なくとも、非推奨のメソッドを削除する前に1つのバージョンに保持する必要があります。最大時間はないと思いますが、実際に削除しないと、廃止は少し無意味になります。

メジャーバージョンリリースは、非推奨のメソッドを削除する良い機会です。マイナーリリースには、通常、重大な変更が含まれるべきではありません。cHaoがコメントで指摘したように、廃止は必ずしも最終的な削除があることを意味するものではありません。

これは、ユーザーにどのような安定性の保証を与えたか、およびユーザーにどの程度の痛みを与えたいかだけに依存します。

理想的には、APIがsemverを使用するため、重大な変更があるとメジャーバージョン番号が増分されます。実際には、これを行うことはほとんどありません。APIがパッケージマネージャーを介してインストールされている場合、簡単なアップグレードで競合が発生しないように（myapi2 v2.123.4vsなどmyapi3 v3.2.1）、重大な変更後に新しいパッケージ名を作成することができます。あなたのパッケージマネージャがサポートするより厳しいバージョン依存関係（のような例依存仕様ならばそれは不要かもしれ~v2.120含まれていませんv3.*）が、異なるパッケージ名は、互換性のないバージョンが非常に簡単に並べて使用することができることが利点を持っています。semverを使用する場合でも、廃止期間を設けることは賢明です。

Semverは常に適用できるとは限りません。次に、明確な安定性ポリシーを伝えることがより重要です。例えば：

• 実験的な機能は予告なく削除される場合があります。
• 機能は、セキュリティ上の理由でいつでも削除される場合があります。
• 他の機能は削除されるだけです
  • …リリース版で廃止された後
  • …そのバージョンが少なくとも3か月前のもの
  • …そして、メジャーバージョンではバンプでマークされます。

このようなポリシーは、定期的なリリースがある場合に特に有効であるため、1年などの明確な非推奨期間があります。

APIの一部を非推奨としてマークする以外に、非推奨を広く知らせる必要があります。例えば：

• 将来の方向性と非推奨についての変更ログのセクションを用意してください。
• 非推奨を実行する前に非推奨の意思をブロードキャストし、コミュニティに耳を傾けて実質的な異論があるかどうかを確認します。
• これらの変更がもたらすメリットを伝えてください。ユーザーベースによっては、ニュースレター、プレゼンテーション、ブログ投稿、またはプレスリリースが適切なメディアになる場合があります。「私たちは素晴らしい新機能を作成しています！（この広く使用されている古い機能を削除する必要があります）」は、コンテキストなしで機能を削除するよりも少しイライラしません。

選択すべき正確な非推奨期間については、まずユーザーとのサポート契約を尊重する必要があるかどうかを確認してください。このような契約では、一定期間互換性を維持する必要がある場合があります。そうでない場合は、下流への影響を考慮してください。ダウンストリームユーザーよりも急速に変更しないようにして、ユーザーが独自の非推奨サイクルを経験できるようにします。下流のユーザーは変更に適応するのに時間がかかるため、1か月より短い廃止期間を設けないでください。

理想的には、廃止されたメソッドを使用しているユーザーがなくなるまで待つことをお勧めします。パブリックAPIを使用していることを考えると、簡単に追跡できますが、非常に長い時間がかかる可能性があります。

2015年、GoogleはAndroid OSのstlport APIで同様の問題を抱えていました。彼らはそれを廃止し、それを削除したかったが、多くのアプリがまだそれを使用していた。彼らは賢い解決策を見つけました。

基本的に、開発者向けの適切なログメッセージでAPIを使用しているアプリの起動時に8秒のsleep（）を追加しました。1か月後、彼らはそれを16秒に倍増しました。それから1か月後、誰もAPIインターフェースを使用していなかったため、APIインターフェースを安全に削除できました。

これは非常に効果的な方法です。唯一の本当の問題は、APIが非常に古く、アクティブにサポートされなくなったコンシューマーをアクティブに使用している場合です。残念ながら、このようなコンシューマーを自分で修正することはおそらくできないでしょうが、その時点ではメソッドを削除してコンシューマーを破壊する以上のことはできません。

非推奨のメソッドを提供する最小時間は、APIを使用するプログラムの開発サイクルによって異なります。概算として、1年で十分です。

非推奨のメソッドを削除する必要があるまでの最大時間については、そのようなことはないと主張します。どれだけ長く待っても、廃止されたメソッドを削除すると、常に何かが壊れます。廃止されたAPIを使用する一部のプログラムは積極的に保守されていません。互換性を破ると、そのようなプログラムの寿命が終わります。

削除から何かを得たら、非推奨のメソッドを削除することをお勧めします。

• 非推奨のメソッドに特に影響するバグが検出された
• コードをリファクタリングしようとしており、非推奨のメソッドを維持するには多大な労力が必要です
• ライブラリの内部構造を最適化しているため、廃止されたメソッドはもはや適合しません。

廃止されたメソッドをXか月/年廃止されたという理由だけで削除するか、新しいバージョンをリリースすることは正当な理由なく互換性をarbitrarily意的に損なうことになります。

最初に、廃止するか廃止するかを検討する必要があります。

非推奨は、何らかの方法で有害なメソッド（セキュリティ、パフォーマンス、誤った結果）に使用する必要があります。比較的迅速に、2つ以上のメジャーバージョンを削除し、3日までに削除する必要があります。十分に重大な問題については、次のマイナーバージョンで廃止予定が削除される可能性があります。

廃止されたのは、何らかの理由であまり役に立たないもの、たとえば、返される情報が少ない、またはうまく機能しない、多くのオプションが含まれていないなどです。これらは無期限にぶらぶらすることがありますが、少なくとも次のメジャーバージョンに存在する必要があります。

答えは、顧客に提供しているサービスの種類によって異なります。

極端な理由の1つとして、Microsoftは下位互換性を非常に強く信じていたため、Win 3.1時代のWindows.hに20年にわたって広まった誤りがあります。

スペクトルのもう一方の端では、多くのWebアプリは非推奨の警告を提供することなく機能を削除します。

多くの場合、クライアントがあなたのソフトウェアにどれだけのお金を払っているのかが重要です。通常、研究科学者は、銀行家やFAAなどよりも、進歩の一部として非推奨を受け入れようとします。

私は社内で使用するソフトウェアを開発している会社で働いていました。私は長年にわたって多くのグループを支援しました。1つのグループには「機能を削除しない」という考え方がありました。5〜10年前にファイルに戻って、開発者が機能を元に戻すには速すぎるタイムスケールで分析する必要がありました。1つのグループの姿勢は、後で見つけることができます。」途中に、「削除する前に使用する場合は、機能を少なくとも1つのバージョンで非推奨にする必要がある」というルールを持つグループが1つありました。そのグループには、必要な機能をカバーするテストスイートがありました。新しいバージョンをリリースするたびに、彼らはテストスイートをすぐに実行して、廃止されたものが問題を引き起こしたかどうかを確認しました。

私はパブリックAPIを保守しており、メソッドを廃止する必要があります。

なぜこれをする必要があるのですか？それは、物事を行うための新しい光沢のある方法があるため、古い方法は今では推奨されていませんが、それでもうまく動作するからですか？それとも、物事が根本的に変わったので、古い方法は実際に行く必要がありますか？

• 古い方法が実際の問題を引き起こしておらず、その問題を回避できる場合は、同様に問題がある可能性があります。壊れていない場合は、修正しないでください。本当に削除する必要がありますか？多分それを時代遅れとしてマークし、別の方法がより効率的であるかもしれない、または何であれ、ドキュメントにメモを含めてください。

• 古い方法が本当に必要な場合は、メンテナンスの頭痛の原因になっているため、または他の変更のためにもはや意味をなさないため、その使用を監視し、クライアントに非推奨を明確に伝えます。明確な日付を指定してから、メソッドを削除してください。（理想的には、この日にすぐに実際に削除しないでください。実際に削除する前に、まだ誰も使用していないのを待ってください。実際に問題を引き起こしている場合は、早めに行く必要がありますが、少なくとも使用法が削除されるのを待ってください少し。）

• 古い方法がセキュリティ上の問題を引き起こしている場合は、それよりも速く移動する必要があるかもしれませんが、警告なしに削除することもできますが、この変更を非常に目に見える場所に文書化し、古い方法を使用しようとするクライアントに適切なメッセージを返す必要があります。

（2番目の2つの箇条書きは他の回答で十分にカバーされていますが、最初の1つは新しいと思います。）

公開プロジェクトの場合は、必要な場合にのみ削除してください。

不要なAPIの削除を行うと、企業や請負業者に費用がかかり、費用のかかる解約のために計算することさえできなくなります。

企業や独立したプログラマーにプロジェクトの使用をやめてもらいたいですか？あなたが不可欠ではないとき、彼らのものを十分な回数壊してください、そして、あなたはあっという間にそのボートにいるでしょう。

deprecation != eventual_removal。APIが危険な場合は、削除します。古い場合はそのままにして、交換を文書化します。