本番プロジェクトでサードパーティのライブラリ/コンポーネントを使用する場合、そのライブラリのリリース済みバージョンのみを使用することに厳格ですか?
ライブラリのプレリリース版またはベータ版の使用を検討するのはいつですか?
ライブラリのバグや欠点に遭遇し、すでにそれを使用することにコミットしている場合、ライブラリにパッチを適用するか、コードで回避策を作成しますか?
本番プロジェクトでサードパーティのライブラリ/コンポーネントを使用する場合、そのライブラリのリリース済みバージョンのみを使用することに厳格ですか?
ライブラリのプレリリース版またはベータ版の使用を検討するのはいつですか?
ライブラリのバグや欠点に遭遇し、すでにそれを使用することにコミットしている場合、ライブラリにパッチを適用するか、コードで回避策を作成しますか?
私は、他の誰かが、私が合理的な時間内にコーディングできなかったバージョンを持っている場合、または長期的には問題にならないものの専門家になる必要がある場合、何かをコーディングしないことを大いに好みます。
Quartz.NET、Log4Net、nLog、SharpFTPLibrary (大幅に変更) など、実稼働環境で使用したオープン ソース コンポーネントとライブラリがいくつかあります。Quartz.NET は、私が最初にそれを使用するアプリケーションを本番環境にリリースしたときはベータ版でした。これは非常に安定したベータ版で、ソース コードを持っていたので問題をデバッグできましたが、問題がいくつかありました。バグやエラーに遭遇したとき、私はそれを修正し、その問題をバグトラッカーまたは作者に投稿しました。問題をデバッグするためのソースが利用できる場合、または問題を突き止めている開発者に強い支持がある場合は、ベータ版製品を使用することに非常に満足しています。
以前は商用プロジェクトでベータ版ライブラリを使用したことがありますが、ほとんどは開発中、および製品を完成させる前にベンダーが最終バージョンをリリースする可能性が高いときに使用しました。
たとえば、Visual Studio 2005 Beta 2 を使用して小さなデスクトップ アプリケーションを開発したのは、アプリの最終リリース前に RTM バージョンが利用可能になることを知っていたからです。また、別のプロジェクトの開発中に FirebirdSQL ADO.NET Driver のベータ版を使用しました。
バグについては、再現する方法がある場合はいつでも完全なバグ レポートを投稿するようにしていますが、ほとんどの場合、アプリケーションをできるだけ早くリリースするための回避策を見つける必要があります。
私が使う:
これらのすべてに重大なバグが見つかったので、それらの使用をできるだけ制限するようにしています。Infragisitcs はそれ自体が非常に優れており、National Instruments は非常に限定的ではありますが、群を抜いて優れています。LeadTools は絶対に避けます。
本番環境で使用することが確実でない場合、dev でベータ版を使用しても意味がありません。無駄な練習にしか見えない
なるほど、devでプレリリース版を評価するシナリオも考えていたのですが、dev -> test/qa -> prodのパスを汚すのではないかと思いました。
パッチを使用します。お金を払ってでもコードを書く必要はありません。
それが商用ライブラリではなく、オープンソースのライブラリである場合はどうなりますか? 適用するパッチがリリース エンティティ (独自のパッチなど) からのものではない場合はどうなりますか?