複数のバックエンドバージョンをサポートするフロントエンド-下位互換性の維持
幅広い質問であることは承知しているので、できるだけ具体的に説明するようにします。この質問は、おそらく技術的な質問と同じくらい「組織的な」質問です。
私たちの会社は、10社の顧客（企業も含む）と言って、ソフトウェア/プラットフォームを販売しています。これらの顧客はすべて私たちのプラットフォームの独自のインストールを実行しており、これらのすべての顧客が現在プラットフォームのバージョン1を実行しているとしましょう。
これで、バックエンドのバージョン2を作成して、新しい機能を含め、場合によっては既存のデータモデルをいくつか変更します。つまり、これにより、フロントエンドバージョン1の重大な変更が導入されます。
ただし、すべてのお客様がバックエンドバージョン2を購入するわけではありませんが、新しい（マイナー）フォントエンド機能は引き続き提供されます。これらの新しいフロントエンド機能の一部は、バックエンドバージョン2を購入するお客様はバックエンドバージョン2に依存する可能性がありますが、他のお客様はバックエンドバージョン1の既存のエンドポイントに依存するようにします。
ここでの大きな問題は、フロントエンドでこれを処理するための最良の方法は何でしょうか。バックエンドバージョン2に依存するフロントエンドバージョン2を作成することを提案できますが、前述のように、バックエンドの両方のバージョン2で動作する必要がある新しいフロントエンド機能を開発する必要がある場合があります。また、バックエンドのバージョン2を購入しないお客様向けのバージョン1。
-ここでの大きな欠点は、フロントエンドですべての新しい機能を2回作成する必要があることです（フロントエンドのバージョン1で1回、バージョン2で1回）。
別のアプローチは、フロントエンドの1つのバージョンを維持し、顧客がバックエンドバージョン2を持っているかどうかを示す設定/変数に基づいて、バックエンドバージョン1または2のいずれかに依存する新機能を持つことです。
-ここでの大きな欠点は、すべての機能に対して、多くのif-elseステートメントを実装する必要があることです（if（hasVersion2）{バックエンドのバージョン2を使用} .. else {バックエンドのバージョン1を使用} ）。
現在、これを最も効果的に処理する方法についての入力/フィードバック/経験を探しています。たぶんあなたはいくつかの関連する経験を持っています。
TL; DR;バックエンドの新しいバージョンとレガシーバージョンのバックエンドの両方で動作する必要がある新しいフロントエンド機能と改善をどのように処理しますか？
オプション：
1）ユーザーはアップグレードまたはハングアップできます。バージョン1.Xは、Y日のX日目にサポートされなくなります。
2）今後は両方の回線をサポートします。私の記憶は Joel で投稿を小刻みに動かしていますが、現時点では製品を思い出せません。問題の解決策を3回設計した会社があります。彼らはV1を構築し、それをV2として再構築することを学び、テクノロジーが再び変化したときに、V3として再構築しました。 V1、V2、およびV3は個別に提供される個別のソフトウェア製品ですが、すべてアクティブに保守されています。
3）重大な変更を導入しないでください。バックエンドにV1およびV2インターフェースを提供します。それが内部スーパーモデルをV1/V2仕様にうまく適合させることを意味する場合。 V1セマンティクスをエミュレート/シミュレーションすることを意味する場合は、それを提供します。それがドロップされた振る舞いを提供するプラグインを書くことを意味するなら、それを書いてください。顧客は、クライアントを裏返すことなく、更新とアップグレードを受け取ることができます。新しい機能がV1だけで機能する場合は、両方のクライアントで機能できます。それ以外の場合は、V2のみの機能です。
4）V2を記述しないでください。 V1を改善するだけです。代替クライアントを提供する場合は、先に進んでください。それ以外の場合は、バックエンドの報告された機能に基づいて機能を提供する単一のクライアントを持つことができます。これはまた、クライアントに実際のサービスを提供するサーバー側プラグインを提供するための素晴らしいプラットフォームを提供します。