未発表のプロジェクトはどのバージョン番号を受け取るべきですか？

Question

注：バージョン番号は初めてです。私の無知を許してください。

私は、主要なリリースの試み（バージョンb）が放棄された後、後に再検討されてリリース（バージョンC）を放棄しました。各バージョンには、以前のバージョンからの大きな変更があり、マイナーアップデートは考慮されません。バージョンBのものはほとんどありません。バージョンCになりました。

バージョンA（1.0）

• 開発、リリース、更新など。

バージョンB（???）

• 開発、中断、放棄されました。

バージョンC（2.0）

• 開発、リリース、更新など。

私はそれらのようなバージョンを持っているべきだと感じていますが、欠落しているバージョンの混乱を心配しています：

• バージョンA（1.0）
• バージョンB（2.0）
• バージョンC（3.0）

Answer 1

マーケティングの悪夢でない限り、私は不足しているバージョン番号を気にしません。開発ビューポイントから、それは単なるポインターであり、特定のポイントを過ぎると、以前のバージョンは将来のバージョンを構築するためのレッスンとしてのみ機能しました。あなたが言ったように - バージョンBのほとんどがバージョンCになりましたので、バージョンBの存在を認めるポイントは何ですか？

マーケティング - バージョン番号をスキップする会社がたくさんあります。顧客が混乱している場合は、あなたがあなたの製品を改善するためにそのような大きな進歩を遂げたことを彼らに伝えてください。反対側は、顧客がソフトウェアパッケージのバージョン2.9を受け取った場合、バージョン3.0の無料コピーを受ける権利があると感じることがあることがあります。結局のところ、それは2.9のかかとにありました。彼らのトラックでそれらを止めて、4.0の命名規則によってあなたの努力のためにもう少しお金を取ります。

これはまた、存在しないバージョンをEOLにできるようにすることでEOLを発表するのに役立ちます。オフ。

それはマインドゲームです - あなたはあなたの相手がそうする前にロシアと中国をコントロールする必要があります。それが彼らがそれを呼ぶ理由です 危険.

Answer 2

2つのバージョンスキームが必要です。典型的な形式に従う内部のもの：

major.minor.build.revision

そして、それに直面している公衆。パブリックに直面していると、内部バージョンを「顧客フレンドリー」という名前のバージョンにマッピングできます。 Javaの命名戦略に関する歓喜のように。

Answer 3

マルチドットバージョンの番号付けは時間の無駄です。接吻。バージョン1から始めて、1を増やし、整数に固執します。余分な期間と数字を強制するシステムを使用している場合は、それらを無視してください。各バージョンに固有のもの、リリースされたとき、リリースされた人などの適切なログを保持してください。誰でも、アップグレードするかどうかについての「新しい」ドキュメントではなく、バージョン番号のみで決定することは誰でも関係していません。約。

Answer 4

バージョンBがリリースされなかった場合、バージョンCは2.0のパブリックリリース番号でリリースできます。あなたはそれを作らなかった内部リリースを持っていることを認める必要はありません。マッピングを追跡している限り、内部バージョン番号は、パブリックリリース番号を一致させる必要はありません。