プロジェクトで使用するオープンソースフレームワークの変化にどのように対処しますか?
それは私の個人的な癖かもしれませんが、私は生きているプロジェクトのコードを最新の状態に保つことが好きです-彼らが使用するライブラリー/フレームワークを含みます。その一部は、完全にパッチが適用され、最新の状態になっている場合、Webアプリの方がより安全であると考えていることです。その一部は、私の部分的な強迫性のほんの一部です。 過去7か月間で、ソフトウェアの大幅な書き換えを行いました。遅くて本質的に製品として死んでいたXarayaフレームワークを削除し、Cake PHPに変換しました。(私たちがCakeを選んだ理由は、ソフトウェアを非常に迅速に書き直す機会があり、Xarayaを十分にパフォーマンスを向上させてしばらくの間価値があるためです。) SimpleTestを使用して単体テストを実装し、すべてのファイルおよびデータベースの命名規則などに従いました。 Cakeは2.0に更新されています。そして、アップグレードのための実行可能な移行パスがないようです。ファイルの命名規則は根本的に変更され、PHPUnitに代わってSimpleTestが廃止されました。 なんらかの変換ツールがない限り、Cakeを更新してレガシーコードを徐々に改善して新しいCakeフレームワークのメリットを享受することは不可能であるため、これはほぼ1.3ブランチに留まることを強制します。 。そのため、いつものように、Subversionリポジトリに古いフレームワークが作成され、必要に応じてパッチを適用します。 そして、これが毎回私を魅了するものです。そのため、多くのオープンソース製品は、それらに基づくプロジェクトを最新の状態に保つのに十分なほど簡単ではありません。開発者が新しい光沢のあるおもちゃで遊び始めると、いくつかの重要なパッチが古いブランチに適用されますが、彼らの焦点のほとんどは新しいコードベースに置かれます。 使用しているオープンソースプロジェクトの急激な変化にどのように対処しますか?また、オープンソース製品を開発している場合、新しいバージョンを開発する際にアップグレードパスを念頭に置いていますか?