廃止されたメソッドを削除するまでにどれくらいの時間がかかりますか？
私はパブリックAPIを維持しており、メソッドを廃止する必要があります。
メソッドを廃止する必要がある削除までの月数、年数、バージョン数に関する一般的なルールはありますか？
少なくとも、非推奨のメソッドを削除する前に1つのバージョンで保持する必要があります。最大時間はないと思いますが、実際に削除しないと、廃止は少し無意味になります。
メジャーバージョンのリリースは、非推奨のメソッドを削除する良い機会です。マイナーリリースには通常、重大な変更が含まれていません。 cHaoがコメントで述べたように、非推奨は必ずしも最終的に削除されることを意味するわけではないため、非推奨後に削除する予定がある場合は、そのことを明示し、タイムラインに関するガイダンスを提供する必要があります。
これは、ユーザーにどのような安定性を保証するか、およびユーザーにどの程度の苦痛を与えたいかにのみ依存します。
理想的には、APIは semver を使用して、重大な変更によりメジャーバージョン番号が増分されるようにします。実際には、これを行うことはほとんどありません。 APIがいくつかのパッケージマネージャーを介してインストールされている場合、単純なアップグレードで競合が発生しないように、重大な変更の後に新しいパッケージ名を作成することができます（例：myapi2 v2.123.4対myapi3 v3.2.1）。パッケージマネージャーがより緊密なバージョンの依存関係をサポートしている場合（たとえば、~v2.120含まないv3.*）ですが、異なるパッケージ名には、互換性のないバージョンを非常に簡単に並べて使用できるという利点があります。 semverを使用する場合でも、非推奨期間を設けることは理にかなっています。
Semverは常に適用できるわけではありません。次に、明確な安定政策を伝えることがより重要です。例えば：
- 実験的な機能は予告なく削除される場合があります。
- セキュリティ上の理由から、機能はいつでも削除される場合があります。
- その他の機能は削除されます
- …リリースされたバージョンで廃止された後
- …そのバージョンが少なくとも3か月前のもの
- …そしてメジャーバージョンではバンプによってマークされます。
このようなポリシーは、定期的なリリースがあり、廃止期間が明確になっている場合に特に有効です。一年。
APIの一部を非推奨としてマークする以外に、非推奨を広く知らせておく必要があります。例えば：
- 将来の方向性と廃止予定に関する変更ログのセクションを用意してください。
- 非推奨にする前に、非推奨にする意向を伝え、コミュニティに耳を傾け、大きな異議がないかどうかを確認します。
- これらの変更からどのようなメリットがもたらされるかを伝えます。ユーザーベースによっては、ニュースレター、プレゼンテーション、ブログ投稿、プレスリリースなどが適切なメディアとなる場合があります。 「私たちは素晴らしい新機能を作成しています！ （この広く使用されている古い機能を削除する必要があります）」は、コンテキストなしで機能を削除するよりも少しイライラします。
選択する正確な非推奨期間については、まずユーザーとのサポート契約を守る必要があるかどうかを確認します。このような契約では、一定期間、互換性を維持する必要がある場合があります。そうでない場合は、下流への影響を考慮してください。ダウンストリームのユーザーよりも変更を速くしないようにして、ユーザーが独自の非推奨サイクルを実行できるようにします。ダウンストリームユーザーは変更に適応するのに時間がかかるため、非推奨期間を1か月より短くすることはできません。
理想的には、廃止されたメソッドを誰も使用しなくなるまで待つことをお勧めします。パブリックAPIを使用していることを考えると、追跡は簡単ですが、非常に長い時間待機することになります。
2015年、GoogleはAndroid OSのstlport APIで同様の問題を抱えていました。廃止予定で削除したかったのですが、多くのアプリがまだそれを使用しています。巧妙な解決策を見つけました：
基本的に、開発者向けの適切なログメッセージでAPIをまだ使用しているアプリの起動中に、8秒のsleep（）を追加しました。 1か月後、彼らはそれを2倍にして16秒にした。その後1か月後、誰もAPIインターフェースを使用しなくなったため、APIインターフェースを安全に削除できました。
これは非常に効果的な方法です。唯一の実際の問題は、APIが非常に古く、アクティブにサポートされなくなったコンシューマーをアクティブに使用している場合です。残念ながら、おそらくそのようなコンシューマーを自分で修正することはできませんが、その時点では、メソッドを削除してコンシューマーを破壊する以上のことはできません。
非推奨のメソッドを提供するための最小時間は、APIを使用するプログラムの開発サイクルによって異なります。おおよその数値として、1年で十分です。
廃止されたメソッドを削除するまでの最大時間については、そのようなことはないと主張します。どれだけ長く待機しても、廃止されたメソッドを削除すると、常に何かが壊れます。廃止されたAPIを使用する一部のプログラムはアクティブに維持されておらず、互換性が失われると、そのようなプログラムのサポートが終了します。
削除から何かを得るの場合、非推奨のメソッドを削除することをお勧めします。
- 廃止されたメソッドに特に影響するバグが検出された
- コードをリファクタリングしようとしていて、非推奨のメソッドを維持するにはかなりの労力が必要になります
- ライブラリの内部構造を最適化しているため、廃止されたメソッドはもう適合しません。
Xか月/年の間非推奨になったため、または新しいバージョンをリリースしているために非推奨のメソッドを削除すると、正当な理由なく互換性が恣意的に損なわれることになります。
まず、廃止するか廃止するかを検討する必要があります。
セキュリティ、パフォーマンス、誤った結果など、何らかの形で有害なメソッドには非推奨を使用する必要があります。あなたはそれらを比較的早く、2つ以下のメジャーバージョンを取り除き、3番目に消えたいと思っています。十分に重大な問題が発生した場合は、次のマイナーバージョンで非推奨のものを削除する可能性があります。
廃止とは、何らかの理由であまり役に立たないものの場合です。たとえば、返される情報が少ない、または機能しない、オプションが多くないなどです。これらは無期限にハングアップする可能性がありますが、少なくとも次のメジャーバージョンに存在する必要があります。
答えは、顧客にどのようなサービスを提供しているかによって異なります。
Microsoftは後方互換性を非常に強く信じていたため、極端に言えば、Windows 3.1時代のWindows.hには20年間にわたって広まった間違いがあります。
反対に、多くのWebアプリは機能を削除しますが、非推奨の警告も表示しません。
多くの場合、クライアントがソフトウェアに支払う金額は、その業務内容と同様に重要です。研究科学者は通常、銀行やFAAよりも、進歩の行進の一部として非推奨を受け入れたいと考えています。
私は社内で使用するソフトウェアを開発する会社で働いていました。私は長年にわたって多くのグループをサポートしてきました。 1つのグループには、「機能を削除しない」という考え方がありました。 5〜10年前にファイルに戻ってタイムスケールでファイルを分析し、開発者が機能を元に戻すことができないようにする必要がありました。後で見つけることができます。」真ん中には、「機能を削除する前に使用すると、機能が少なくとも1つのバージョンで非推奨になり、警告が表示される」というグループが1つありました。そのグループには、必要な機能をカバーするテストスイートがありました。私たちが新しいバージョンをリリースするときはいつでも、彼らはテストスイートをすぐに実行し、サポート終了により問題が発生したかどうかを確認しました。
私はパブリックAPIを維持しており、メソッドを廃止する必要があります。
なぜこれを行う必要があるのですか？それは物事を行うための新しい光沢のある方法があるためですか？古い方法は今は推奨されませんが、それでもうまく機能しますか？あるいは、物事が根本的に変わったので、古い方法は実際に行く必要がありますか？
古い方法が実際の問題を引き起こしておらず、canが残っている場合は、それも原因である可能性があります。 破損していない場合は修正しないでください本当に削除する必要がありますか？多分それを時代遅れとしてマークし、別の方法がより効率的であるかもしれない、または何であれ、ドキュメントに注記を含めますが、おそらくそのままにしておくのが良いでしょう。
古い方法が本当に必要である場合、それはメンテナンスの問題を引き起こしているため、または他の変更のためにもはや意味をなさないため、その使用法を監視し、廃止予定をクライアントに明確に伝えます。メソッドが削除される日付を明記してください。 （理想的には、この日にすぐに実際に削除しないでください。実際に削除する前に、まだ誰もそれを使用していないまで待ってください。本当に問題を引き起こしている場合は、もっと早く実行する必要があるかもしれませんが、少なくとも使用量が低下するまで待ってください。少し。）
古いメソッドがセキュリティの問題を引き起こしている場合は、それよりも早く移動し、おそらく警告なしに削除する必要があるかもしれませんが、この変更を非常に目に見える場所に文書化し、古いメソッドを使用しようとするクライアントに適切なメッセージを返す必要があります。
（2番目と3番目の箇条書きは他の回答でも十分にカバーされていますが、最初の箇条書きは新しいと思います。）
パブリックプロジェクトの場合は、削除するだけです必要な場合のみ必要です。
不要なAPIの削除を行うと、企業や請負業者に費用がかかり、高額な解約が原因で計算すらできなくなります。
会社や独立したプログラマーにプロジェクトの使用をやめてもらいたいですか？あなたが必須ではなく、すぐにそのボートに乗っているときに、十分にそれらを壊してください。
deprecation != eventual_removal。 APIが危険な場合は削除します。古い場合は、そのままにして、交換品を記録します。