プロジェクトを分岐しました。バージョン番号はどこから始まりますか？

私はプロジェクトを分岐し、その多くを変更しました。この分岐は、ここでの小さな機能の変更や、そこに埋められたバグの修正ではなく、かなり大きな変更です。ほとんどのコアコードのみが共有されます。

このプロジェクトはv2.5.0で分岐しました。しばらくの間、v3.0でフォークのバージョン管理を開始しました。ただし、これが正しい方法かどうかはわかりません。主にそのプロジェクトがv3.0に到達すると、混乱するからです。しかし、私はv1.0またはv0.1からやり直したくありません。これは、プロジェクトの初期段階、不安定性、および非検索性を意味するためです。ほとんどのコアコードは非常に洗練され安定しているため、これは事実ではありません。

私は何をすべきか本当に失望しているので、ここで尋ねます：この種の状況に対処する標準的な方法は何ですか？ほとんどの分岐は最初からやり直したり、バージョン番号を上げたり、私が知らない何かをします。

私が見たほとんどのフォークは、バージョン1.0から再び始まります。しかし、フォークの名前も変更したと思われるため、v3.0から開始しただけで混乱が生じる理由はわかりません。

プロジェクトの名前を変更し、バージョン1.0をリリースし、そのプロジェクトが別のプロジェクトの分岐であることを明確にします。そのアプローチに混乱はないと思います。

「1.0」ラベルが本当に心配な場合は、1.0の少し後にバージョン2.0をリリースしてください。

独自のロードマップを用意して、元のバージョンの番号から始めてください。ただし、元の製品の現在のバージョンと競合しようとしないでください。

プロジェクトが元のプロジェクトと関連するかどうか（およびその程度）を検討することをお勧めします。元のプロジェクトから新しい機能を自分のプロジェクトに移植する予定がある場合は、元のバージョンとバージョン番号を一致させることを検討してください。

例として、MySQLのフォークであるMariaDBをチェックしてください。彼らはそれをMySQLの「ドロップイン」代替品にしたいので、例えばMariaDB 5.2はMySQL 5.2のすべての機能を備えています。

参照：http : //kb.askmonty.org/v/mariadb-versus-mysql

注：この回答が投稿されてから、MariaDBはMySQLから大幅に分岐し、独自のバージョン管理スキームに従っています。

0.1は幼児期を示しますが、バージョン1.0+は安定を意味します。2.0、3.0などのメジャーバージョン番号の増加は、通常、大きな機能変更を示しています。

例えば

• 私のアプリケーションのバージョン1.0は、セットアップでテストスクリプトを実行するためのツールでした。
• バージョン2.0では、テストスクリプトと環境セットアップスクリプトの区別がなくなり、
• バージョン3.0では、フローチャートとしてスクリプトを記述するためのGUIが追加されました。それらは明らかに異なる製品ですが、バージョン1でも動作する製品であり、完全に安定しているなどです。バージョン2および3は、これらの大きな変更が適切であると判断されたために生まれました。これらの大きな変更を望んでおらず、バグ修正などを続けていた場合、マイナーバージョン番号は1.10、1.20などに増えただけで、それで問題ありませんでした。

私が言っているのは、メジャーバージョン番号は成熟度ではなく、主要な機能セットを示しているということです。 これは、製品のバージョン番号の付け方とは少し異なります。

私が静かに気に入っていたのは、1.0（または本当に必要な場合は3.0）から再びバージョン管理を開始し、最後に元のバージョンの機能が最後に取得されたことを括弧内に示したことです。

• 初期： " MyFork v1.1（OrigProg v3.0ベース）
• MyFork：MyFork v1.3（OrigProg v3.0に基づく）に対する改良点
• OrigProgはメジャーバージョンをリリースし、MyForkはプルおよびマージされました：MyFork v2.1（OrigProg v4.0に基づく）
• MyForkにいくつかの大きな変更を加えました（おそらくOrigProgと再び簡単にマージすることはおそらくできないでしょう）：MyFork v3.0（OrigProg v4.0に基づく）

可能であれば、フォークを元のプロジェクトにマージします。これを十分に強調することはできません。

バージョン番号を取得し、分岐元のバージョンと日付のサフィックスを使用します。