2

私は、知らない多くの人々によって使用されているプロジェクトに取り組んでいます。私たちは CheckStyle の警告を下げるというかなり良い仕事をしており、バイナリ互換性を壊すことなく得ることができるほど低いものです.

残りの警告の大部分は、定数 (public static final) に final キーワードがないことが原因です。定数の命名は、開発者がそれらを読み取り専用にすることを意図していたことを明らかにしていますが、それらには final が定義されていませんでした。

開発者がこの見落としを利用したかなりひどいコードを書いていない限り、それらを追加してもコードが壊れることはありません。

現在のバージョン番号は 1.2.1 です。変更を適用して 2.0 に移行しますか、それとも適用して 1.3 としてロールアウトしますか。完全な 2.0 を必要とするのはかなり小さな変更のようです。

私は何をすべきか？

4

4 に答える 4

4

私の意見では、バイナリ互換性を損なう可能性のあるこのような変更は、メジャー バージョンがリリースされるまで延期する必要があります。つまり、質問は「どのバージョン番号を使用すればよいか」ではなく、「これらの変更をいつ行うべきか」であるべきです。

バイナリ互換性に完全にコミットしている場合は、アップグレードのコストを正当化する大幅な改善が含まれるリリースまで、これらの変更を延期する必要があります。たとえば、KDE ​​プロジェクトはメジャー リリースにバイナリ互換性要件を課しています。これは、そのリリースの存続期間中の改善によって、古いバージョンに対してコンパイルされたアプリケーションが壊れないことを意味します。そのため、コードをクリーンアップしたい開発者は、次のメジャー バージョンまで待たなければなりません。

気の利いた新機能をすべて備えたメジャー リリースをリリースする準備ができたら、先に進んで、必要と思われるバイナリ互換性の変更を行います。その場合、何かが壊れてもそれほど驚くことではありません。

巧妙になりたい場合は、プリプロセッサを実装してコードを 2 回コンパイルできます。これは真の決勝戦への足がかりとして使用できますが、その間の維持費は高くなります。

于 2009-10-19T19:44:01.130 に答える
3

あなたはすでにこれを知っていると思いますが、それは「これは安全/シンプル/心配なし」のアップグレードに帰着しなければならないと思いますか？

  • ポイントリリースは安全で日常的なものと見なされます。一部のプロジェクトでは、完全にバグ修正で構成されている必要があります。他のプロジェクトには、問題が発生する可能性が低い場合に新しい機能が含まれます。
  • 新しいメジャーバージョンのリリースには、適応が必要になる可能性のある進化的な変更が含まれています
  • 新しいメジャーx.0バージョンのリリースは、洗練されたユーザーからは非常に疑わしいと見なされています:-)

次のメジャーバージョンのリリースにどれだけ近づいているかにもよると思います。間もなく、問題のあるポイントリリースのリスクを冒さないでください。いつでもセーフポイントリリースとアルファメジャーリリースを行うことができますが、次のメジャーリリースが将来的になくなると、これは奇妙かもしれません...

于 2009-10-19T19:27:41.040 に答える
2

私はそれらを破ると言います。あなたが変化する静的である場合、あなたは自分が間違っていることを知っている必要があります. ただし、別のリリースに分けて、別の無関係な修正が必要なためにパニックに陥るのではなく、クライアントがスムーズにアップグレードできるようにすることもできます。

于 2009-10-19T19:35:59.543 に答える
0

開発者がこの見落としを利用したかなりひどいコードを書いていない限り、それらを追加してもコードが壊れることはありません。

機能しなくなる以前の非最終クラスのサブクラスを作成するようなものですか?

2.0 にするべきだと思います。1.x シリーズのサポートを維持する必要があります。

さらに、API に関する興味深いビデオがあります。 Joshua Bloch の作成者による「優れた API を設計する方法とその重要性」 は、Java のコア ライブラリであり、現在は Google に取り組んでいます。

于 2009-10-19T19:29:30.180 に答える