複数のライブラリとフレームワークを使用するアプリケーションがありますが、新しい安定バージョンが利用可能になったときに、それらのフレームワークの最新バージョンを使用するようにアプリケーションを更新する必要がありますか？
たとえば、python2.xからpython3.xに、またはSpring2.5からSpring3.0に移行しますが、質問は非常に一般的であり、言語固有ではありません。
最新の安定したフレームワークバージョンを使用するようにアプリケーションを更新し続けると、必要に応じて新しい機能を利用できるようになります。
そうでない場合は、将来的に更新を行う必要があり、アプリケーションを更新するのは大変な作業になります。
これに関するベストプラクティスはありますか？
私は...するだろう。これが理由です。そうしないと、使用するライブラリのセットが古くなります。ある段階で（バグ修正のために）1つをアップグレードする必要があり、その時点で相互互換性のためにいくつかをアップグレードする必要があります。したがって、単純なライブラリのアップグレードはカスケードされます。
私のアプローチは定期的にアップグレードすることですが、すぐにアップグレードするのではなく、時間が許す限り簡単にアップグレードします。そうすれば、自分で設定したタイムスケールで、ライブラリセットを徐々に進めることができます。非互換性は、1つのライブラリをアップグレードして問題を解決したいときに、一連の問題全体に対処する必要はなく、一度に1つのライブラリに対処します。
経験に基づいて、私はこれに対して非常に保守的なアプローチを取ることを好みます。
コンポーネントまたはフレームワークの更新は、いつでも危険を伴う可能性があります。フレームワークに新しいバグが見つかったり、古いフレームワークに関する仮定や回避策が原因で、独自のコードにバグが表示されたりする場合があります。
一般に、すぐに利用したい新機能やバグ修正がない限り、または単に時間がたくさんある場合を除き、単に最新のものに更新するべきではありません! フレームワークの更新は、すべてが正常に機能することを確認するためだけに、多くの再テストを意味する場合があります。
すぐに更新する必要があるのは、依存しているフレームワークのバージョンが制御不能であり、クライアントがアップグレードを実行する可能性が高い場合のみです。これの例は Internet Explorer です - v7 に依存するいくつかの機能があるが、v8 がリリースされ、その機能の動作が変更された場合、クライアントはいつでもアップグレードされるため、すぐにアップグレードする必要があります。反対の例として、.Net 2.0 フレームワークに依存するアプリがある場合、そのためだけに 3.5 フレームワークに対して再コンパイルするべきではありません。フレームワークの 2 つのバージョンが共存しているためです。そのため、(理論的には) アップグレードすると、私が導入する必要のない問題が発生する可能性があります。
秤に物を入れなきゃ……。
1.メリットはありますか
2.-それはあなたを苦しめますか
3.-それはあなたの会社のワークフローを壊しますか; デッドタイムはどのくらいになるのか
自分自身のために...私は最新の技術を持っているのが好きです...これは、バグが少なく、より多くの学習を意味します= P
これは非常に一般的な問題です。溶液はそれほどカットして乾燥していない場合があります。アプリケーションをどのようにサポートするかによって異なります。あなたの質問に基づいて、あなたはこのプロジェクトの長期的な目標を持っているように感じます。その場合は、最新バージョンにアップグレードすることをお勧めします。
ただし、Python 2.x の場合のように、古いバージョンが十分に確立されている場合は、新しいバージョンが出た後もしばらくの間、引き続きサポートを受けることができます。しかし、避けられないことを遅らせないでください。
最新の安定したフレームワーク バージョンを使用するようにアプリケーションを更新し続ければ、必要な場合に備えて新しい機能を利用できます。
これが時期尚早の最適化の本質です。
そうしないと、将来、更新を行う必要が生じる可能性があり、アプリケーションを更新するのは大変な作業になります。
ライブラリ プロバイダーと足並みをそろえて行うことで、何かメリットはありますか? もしそうなら、彼らと歩調を合わせて更新してください。それ以外の場合は、アプリケーションの機能の変更と同じように変更を評価し、意味がある場合は更新します。
ひもの長さはどれくらいですか?
あなたの一般的な質問には、一般的な答えしかありません。その答えは、おそらく、与えられた一連の状況におけるリスクと報酬の比率について、あなたがどのように感じているかです。
大規模な IT 部門は、最新の Windows をすぐに展開しない傾向があります (現在、多くの企業が Windows 7 を全面的に使用しており、多くの企業がまだ XP を使用しているとは思いません (VIsta を考えてください))。しばらくリリースをスキップすることはできないかもしれませんが、Windows IT の一般的な経験則は、サービス パック 1 を待つことです。
アプリとフレームワークの場合 - はい、いくつかの優れた新機能があるかもしれませんが、それらは必要ですか? また、それらを実装する時間はありますか? また、新しいコードに最初からバグがないわけではないことを受け入れますか?
おっと、新しいリリースにはおそらくバグ修正が含まれているでしょう - 良さそうですが、ユーザーが報告しているバグですか? そうでない場合は、なぜわざわざ（「ブルガリア語バージョンのウィンドウでChzeckバージョンのフレームワークを使用しているときに、閉じるをクリックしてクラッシュをキャンセルするかを修正します」）。また、バグ修正により、新しいリリースには新しいバグが含まれます。
リスク/報酬 - あなたの報酬は? アプリの新しいバージョンを販売して、より多くの収益を上げることができますか? あなたのリスクは何ですか？新しいバージョンにバグがある場合の評判の低下、サポート時間 (およびコスト)。
あなたの特定の弦の長さはどれくらいですか?
フレームワーク/ライブラリに依存します。フレームワークが人気があり、十分にサポートされ、十分に文書化され、非常に安定している場合 (Spring など)、私は間違いなくアップグレードします。既存の機能といくつかの新しい機能のすべての種類のバグ修正が得られます。
あまり人気がなく、メンテナンスが行き届いていないフレームワークについては、もう少し注意が必要です。
とにかく、デフォルトは更新するべきだと思います-あなたが言ったように、小さなステップで物事を行う方が簡単です。更新を遅らせると、頭の痛い問題が発生します。ある時点で更新する必要がありますが、ギャップが非常に大きくなり、更新が事実上不可能になります。サポートされなくなったバージョンに行き詰まるでしょう。