私は他の人のためにいくつかのライブラリを維持しています。それぞれのリリースをいくつか行った後、もう一度やり直さなければならない場合は、別の方法で行うことがいくつかあります。
質問は：私はそれらをやり直す必要がありますか？私たちは皆、そのジレンマに直面していると思います-メンテナンス活動の有用性と変化の破壊的な影響のバランスをとる方法。
明らかにバグの場合、変更は必須です。そこにはジレンマはありません。新機能の場合、それは有用性と追加された複雑さの問題です。私はその質問に安心して対処できます。
私が求めているのは、バグ修正と新機能の間のあいまいなスペースです。1つの例は、フレームワーク設計ガイドラインまたはCLS準拠に準拠するためのメンテナンスです。ある図書館では、CLSに準拠することを考えずにそれを書いたのですが、人々はそれを求めました。その結果、uintをintに交換するようにインターフェイスを変更する必要がありました。これは破壊的な変化であり、ほとんど利益はありません（ほとんどの人にとって）。
別の問題：FxCopコンプライアンス。FxCopを満足させるために、いくつかのメソッドのパラメーター名を変更する必要がありました。しかし、これらの変更は実際にはリフレクションを使用する人々にのみ影響します。タイプは変更されず、パラメーターの名前のみが変更されます。
私が今扱っている問題は、フレームワークの設計ガイドラインです。イベントに関するガイドラインでは、イベントには2つの引数を持つ署名が必要であると記載されています:(オブジェクトソース、EventArgs e）。しかし、その日はフレームワークデザインコースに欠席しました;）。私のライブラリのイベントは現在、単一のEventArgs引数のみを取ります。
現在、ライブラリに新しいイベントを追加しています。新しいイベントはフレームワークの設計ガイドラインに従う必要がありますか？またはライブラリですでに確立されているパターン？新しいイベントの設計ガイドラインを使用する場合、設計ガイドラインにも準拠するように既存のイベントを変更する必要がありますか？もしそうなら、どのように移行を行うのですか？[廃止]属性を使用する必要がありますか？リリースはいくつですか？
より一般的には、バグ修正と新機能の間のこのあいまいな領域でのメンテナンスについての考えに興味があります。