17

私はセマンティック バージョニング スキームがとても気に入っていますが、重要なのは API のみです。エンドユーザー ソフトウェアなどの非 API の場合、ルールの多くはあまり意味がありません。たとえば、下位互換性という概念そのものは、実際には何の意味もありません。ユーザーが新機能を体験するか体験しないか、バグが少ないか体験しないか、など。ただし、セマンティック バージョニングの精神に従う xyz バージョニングの明確なスキームがあれば、ユーザーは何を期待できるかを理解できるようになります。スキームに精通している場合は、新しいバージョン番号から。

次のようなものをスケッチしてみました。

  • ユーザー エクスペリエンスを変更しないコードの内部変更 (バグ修正、リファクタリングなど) を行う場合は z をバンプします。新しい「内部」機能が含まれる場合があります。
  • バグ修正を超えてユーザー エクスペリエンスを変更する機能を現在の機能に追加する場合は、バンプ y を使用します。
  • バンプ x...???...ユーザー エクスペリエンスに根本的に異なる変化はありますか? 根本的に違うのは何ですか？
  • 最初のアルファ開発は 0.0.z として発生します
  • 最初のベータ テスト リリースは 0.1.0 に設定され、0.yz のままです
  • 最初のユーザー リリースは 1.0.0 に設定されます

別のアイデアは、一部のユーザーがそれらに依存している可能性があるため、機能が削除されたときに x バンプを作成することですが、場合によってはそれは不当に見えるかもしれません。(あなたがすべてのユーザーを知っていて、彼ら全員が非常にマイナーな機能の削除を望んでいるとします。1.0 から 2.0 に移行することは、やや直感に反するでしょう。)

これはセマンティック バージョニングよりも主観的です。後方互換性のある機能や API の破壊的な機能を客観的に特定する方がはるかに簡単だからです。詳細なガイダンスを得るために調査できる「標準化された」バージョン管理スキームはありますか?

4

2 に答える 2

9

私は自分で似たようなものを探していましたが、「公式」なものは見つかりませんでした。ただし、最近、バージョン番号を付けている方法は次のとおりです。

指定された xyz

  • x =ユーザー エクスペリエンスを再設計するたびに増加します。たとえば、Microsoft が Office 2003 と 2007 で行ったように、メイン インターフェイスを再配置します。アプリケーションがユーザー ファイルまたは設定を保存する場合、変更が古いものと下位互換性がない場合は、この番号もインクリメントする必要があります。ファイルまたは設定。

  • y = 基本的に、新しい新しいサブルーチン/関数を追加するたびに増加します。通常、新しいメニュー項目やボタンの追加などはこのカテゴリに分類されます。これは、メニュー項目やボタンのクリック イベントを処理するコールバックを作成する必要があるためです。もう 1 つの例は、ユーザーにとって目立った違いをもたらさないが、管理性を向上させるコードへの変更です (たとえば、最終的に設定ファイルを管理するクラスを作成するようになった場合など)。xがインクリメントされた場合は、この数値をリセットします。

  • z = バグを修正するたびに増加します。xまたはyがインクリメントされた場合は、この数値をリセットします。


注:個人的には、yが 2 桁の数字になったら、 xのインクリメントにつながるユーザー インターフェイスの再設計を検討する時期だと思います。

于 2014-03-06T03:20:49.290 に答える