一般的に、私はジェームス・アンダーソンに同意します。しかし、私の経験では、考慮が必要な追加の側面があり、進化するインターフェイスを実際に許可するオプションを指している場合があります。
この例は、私が作業しているチームの1つからのものです。彼らは定期的に製品を出荷します。少なくとも月に一度、時には毎週です。新しい機能と新しいプラットフォームは新しいバージョンでのみサポートされるため、お客様はアップグレードすることをお勧めします。アップグレードは簡単で、顧客は中間のバージョンをスキップすることもできます。ダウングレードはサポートされていません。さらに、バージョンは3年間のみサポートされます。その後、保守料金が2倍になる猶予期間が1年間あります。
その結果、大多数-顧客の約95%-が少なくとも年に1回は定期的にアップグレードしています。これは、新しいインターフェイスを徐々に導入できることも意味します。
古いインターフェースはどうですか?このチームが使用する手法は、古いインターフェースを「サポート終了」として宣言することです。その後、新しいインターフェイスが利用可能になり、古いインターフェイスがまだ廃止されていない12か月の期間があります。新しいインターフェイスは古いインターフェイスよりも優れた機能を提供するため、2つのインセンティブがあります。古いインターフェイスのサポート終了と新しいインターフェイスの改善です。
この場合の具体的な古いインターフェイスは、プラットフォーム固有のテクノロジーであり、標準的な主流のテクノロジーに基づいたサービスインターフェースに徐々に置き換えられつつあります。
もちろん、この変更は一晩では発生せず、完了するまでに何年もかかります。しかし、古いテクノロジーへの投資をやめ、代わりに新しいテクノロジーへの投資を許可しました。お客様には支援が提供され、今後の道が開けます。彼らのほとんどは、新しいテクノロジーへの動きも歓迎しています。
ただし、この特定のアプローチはシナリオでは機能しない可能性があることに注意してください。それは確かに私が一緒に働いているチームのために機能します。
I think there comes a point where keeping backward compatibility becomes such a big burden that useful changes to interfaces become impossible.
-そして、私は...あなたがあなた自身の質問に答えだと思う