日付を設定し、@deprecated タグで公開します。削除にかかる時間は、コードのユーザー数、ユーザーとのつながり、および変更の理由によって異なります。
何千人ものユーザーがいて、彼らとほとんど話をしていない場合、時間枠はおそらく数十年の範囲になるはずです:-)
ユーザーが 10 人の同僚で、毎日会っている場合、時間枠は簡単に数週間の範囲になる可能性があります。
/**
* @deprecated
* This method will be removed after Halloween!
* @see #newLocationForFunctionality
*/
このように考えてみましょう。顧客 A は、あなたのライブラリ ファイルまたはフレームワークの最新バージョンをダウンロードします。このマシンでコンパイルを実行すると、メンバー ファイルまたは関数が存在しないため、突然何千ものエラーが表示されます。この時点から、新しいバージョンにアップグレードせず、古いバージョンを使用し続ける理由をお客様に説明しました。
Raymond Chen は、win32 API に関する彼のブログでこれに最もよく答えています。
ただし、私たちのソフトウェアハウスでの経験では、API が作成されたら、API を製品ライフサイクルの最後まで使用する必要があります。ユーザーが新しいバージョンを使用できるように、新しいフレームワークの古いコマンドとの下位互換性を提供します。
コードが再構築される頻度によって異なります。たとえば、ライブラリを使用している 4 つのアプリケーションがあり、それらが毎日再構築されている場合、非推奨の呼び出しを修正するには 1 か月で十分です。
また、非推奨のタグを使用する場合は、非推奨の呼び出しを置き換えるコードについてコメントを提供してください。
@deprecatedタグを使用します。詳細については、APIの非推奨に関するドキュメントをお読みください。
コードを使用しているすべての人が自分の側でクリーンアップしたことを伝えたら、非推奨のコードの削除を開始し、誰かが文句を言うかどうかを確認してから、自分のコードを修正するように伝えます...
他のプロジェクトで非推奨がどのように機能するかの例に興味があるかもしれません。たとえば、関数の非推奨に関する Django プロジェクトのポリシーは次のとおりです。
マイナー リリースでは、以前のリリースの特定の機能が廃止される場合があります。バージョン AB の機能が廃止された場合、バージョン A.B+1 でも引き続き機能します。バージョン A.B+2 では、この機能を使用すると PendingDeprecationWarning が発生しますが、引き続き機能します。バージョン A.B+3 では、この機能が完全に削除されます。
これがライブラリであることを考えると、非推奨の関数を含むバージョンをアーカイブすることを検討してください。コードを新しい API に合わせて最新化していないユーザーのためのバックアップ ソリューションとして、このバージョンをソース コードとコンパイルされた形式の両方で利用できるようにします。(バイナリ形式が必要です。数年後に古いバージョンをコンパイルするのに問題が発生する可能性があるためです。) このバージョンはサポートも拡張もされないことを明確にしてください。バージョン管理システムで、このバージョンにシンボリック シンボルのタグを付けます。次に、前進します。
それは確かに、API が使用される規模と、顧客に事前に何を約束したかによって異なります。
Vinko Vrsalovic が説明したように、関数の放棄を予期しなければならない日付を入力する必要があります。
本番環境では、よりクリーンなコードを取得することが「単に」問題である場合、何も壊さない限り、非推奨の日付を過ぎてもそのままにしておく傾向があります。
一方、開発では、物事をすばやく整理するために、すぐに実行します。
あなたが.Netを使用していないのは残念です:(
組み込みのObsolete属性により、コンパイラの警告が生成されます。