注：バージョン番号は初めてです。私の無知を許してください。
試行されたメジャーリリース（バージョンB）が中止され、後で再試行されてリリース（バージョンC）されたプロジェクトがあります。各バージョンには、以前のバージョンからの大きな変更があり、マイナーな更新とは見なされません。バージョンBはほとんどまたはまったくバージョンCになりませんでした。
バージョンA（1.0）
バージョンB（???）
バージョンC（2.0）
私はそれらをそのようにバージョン化する必要があるように感じますが、欠落しているバージョンの混乱を心配しています：
2つのバージョン管理スキームが必要です。典型的な形式に従う内部のもの：
major.minor.build.revision
そして、一般の人と向き合う。公開されているバージョンを使用すると、内部バージョンを「顧客に優しい」名前付きバージョンにマップできます。Javaの命名戦略に関する陽気さのように。
マーケティングの悪夢でない限り、バージョン番号がなくてもかまいません。開発の観点からは、これは単なるポインタであり、特定のポイントを超えると、以前のバージョンは将来のバージョンを構築するためのレッスンとしてのみ機能しました。あなたが言ったように-バージョンBのほとんどがバージョンCになりませんでしたので、内部的にバージョンBの存在を認める意味は何ですか？
マーケティング-バージョン番号をスキップする企業はたくさんあります。顧客が混乱した場合は、製品の改善に大きな進歩を遂げたことを伝えてください。バージョン全体をスキップしました。反対に、ソフトウェアパッケージのバージョン2.9を受け取った場合、バージョン3.0の無料コピーを受け取る権利があると顧客が感じることがあります。結局のところ、それは2.9のすぐ後にありました。それらを彼らのトラックで止めて、4.0の命名規則によってあなたのハードワークのためにもう少しお金を取りなさい。
また、存在しないバージョンをEOLできるようにすることで、EOLの発表にも役立ちます。以前は、ソフトウェアの新しいEOLバージョンを使用している主な人々は、すでに1つのバージョンであるように見えるため、王子のように聞こえます。オフ。
これはマインドゲームです。対戦相手よりも先に、ロシアと中国を支配する必要があります。それが彼らがそれをリスクと呼ぶ理由です。
マルチドットバージョンの番号付けは時間の無駄です。接吻。バージョン1から始めて、1ずつ増やし、整数に固執します。余分なピリオドと数字を強制するシステムを使用している場合は、それらを無視してください。各バージョンに固有のもの、リリースされた時期、リリースされた相手などをログに記録します。アップグレードするかどうかに関する「最新情報」のドキュメントではなく、バージョン番号のみで決定する人は誰でも心配する必要はありません。約。
バージョンBがリリースされていない場合は、バージョンCを公開リリース番号2.0でリリースできます。成功しなかった内部リリースがあることを認める必要はありません。マッピングを追跡している限り、内部バージョン番号は公開リリース番号と一致する必要はありません。