3

改善が欠点をはるかに上回る場合、下位互換性のない変更を導入する必要がある場合があります。古い動作に簡単に切り替えることができますが、ユーザーはそのような変更に注意する必要があります。

したがって問題は、FLOSS (オープンソース) プロジェクトへの将来の下位互換性のない変更をどのようにアナウンスして、ユーザーがそれらの変更に備え、使用を変更するか、古い動作を使用するようにプログラムを構成できるようにするかです。

OSS プロジェクトであるため、さまざまなディストリビューションによって個別にパッケージ化されており、ユーザーの介入なしに自動的にアップグレードされる場合があります。そして、下位互換性のない変更により、誰かのワークフローが混乱する可能性があります (たとえば、サードパーティのスクリプト)。

現在検討されている (および使用されている) アベニュー:

  • プロジェクトメーリングリスト
  • プロジェクトホームページ
  • リリースノート (最初の警告、次に発表)
  • メンテナのブログ

編集 1:この (下位互換性のない) 変更は、いくつかのメジャーリリースで発生します。

すべての変更は、セーフガードを追加するか (初心者ユーザーを完全に混乱させる可能性のあるコマンドを拒否する)、またはデフォルトをより適切な値に変更することに関するものです。

編集 2:移行期間では、デフォルトの構成 (デフォルトの reject/deny に変更されることを意図しています) がwarnに変更され、警告を無効にする方法が説明されています。これにより、デフォルトの動作の下位互換性のない変更からも保護されます。

しかし、それが自動化されたシステムであれば、役に立たないかもしれません...

問題のプロジェクトはGit、分散バージョン管理システムです。gitster のジャーナルでユーザーに早期警告を与える(Junio C Hamano ブログ)を
参照してください。

4

5 に答える 5

9
  • バージョン番号のメジャーを変更する
  • あなたが自由に使えるあらゆる手段を通してそれを発表してください
  • Readme に重要なお知らせを追加
  • DB またはその他の変更が必要な場合は、古いものと新しいものを変換するコードを追加します。
  • 減価償却されたメソッド、データ ストレージなどの使用を検出し、破壊的な変更を実行する前にユーザーに警告するコードを追加します。
  • 主要な Q/A Web サイトで関連する FAQ タイプの質問をして、人々がクエリを持っているときに、単純な検索を使用して答えがすぐにわかるようにします。

しかし、メジャー バージョン番号が主なターゲットです。人々は 1.x から 2.x への移行で問題が発生することを期待しており、アップグレードの際にはより慎重になります。

-アダム

于 2009-02-17T14:01:06.283 に答える
2

あなたは言葉を広めることについて良い答えを持っています。しかし、私自身の考え方を移行することは、特に非推奨の機能が私の筋肉の記憶にある場合、私にとって最大の問題です。非学習は学習よりも難しいです。

変更されるコマンドを実際に使用しているときに非互換性が発生するという警告を受け取ることは、特にデフォルトの変更で特に役立ちます。何かのようなもの： 

 $ git foo  
 Note: git foo currently defaults to HEAD. Starting with
 version 2.0, git foo will instead default to master.
于 2009-02-17T22:09:45.670 に答える
-1

ちょうど私の 0.02 ドル。最新の開発環境 (具体的には .NET) は、特定の API が廃止/非推奨であると宣言され、将来のバージョンで削除されることを開発者に報告する手段を提供します。Microsoft C/C++ コンパイラには#pragma deprecatedがあります。

お使いの環境でこれがサポートされていない場合は、バージョニングを利用して互換性に関するフィードバックを提供してください。

于 2009-02-17T14:02:06.233 に答える