いつバージョン番号を上げる必要がありますか？
私は学校でプログラミングを学んでおらず、（プロの）開発者として働いていません。そのため、多くの基本的なことは私にはあまり明確ではありません。この質問は、それらの1つを明確にすることを試みます。
ここで、Issues Trackerに#1、#2、および#3の問題があり、バージョン1.0.0で修正/拡張されるように設定され、最後の（安定した）と仮定します。バージョンは0.9.0です。
いつバージョン1.0.0に上げる必要がありますか？上記の問題のa）1つだけがクローズされる場合、またはb）allバージョン1.0に関連する問題がクローズされる場合？
正しい方法はどれですか？そしてrightとは、業界で現在使用されているものを意味します。
仕事でどうやってやるか教えてあげます。
バージョン管理されたパッケージをビルド、テスト、タグ付け、出力する継続的インテグレーションサーバーがあります。前のステージが％100成功した場合のみ、次のステージに進みます。
バージョンは次のようになります。<メジャーバージョン>。<マイナーバージョン>。<ビルド番号>
- バグ修正または機能拡張が完了していないビルドが成功するたびに、ビルド番号が増加します。
- バグ修正または機能拡張が完了したビルドが成功するたびに、マイナーバージョンが増加します。これは、特定の形式を使用するコミットメッセージの存在によって自動的に検出されます。このコミットメッセージは、自動的にプロジェクトChangeLogにも取り込まれます。
- 下位互換性のない変更、ゼロからの書き換え、またはケースバイケースで行われたその他の理由がある場合、メジャーバージョンの増分はすべて手動で行われます。
バージョン番号はreleasesにのみ関係します。これは、外部ユーザーがソフトウェアの特定のビルドを識別するための方法であるためです。開発に専念していて、各修正を個別にリリースするのではない場合は、修正ごとにリリース番号を増やす必要はありません。これは外部ユーザーには関係がなく、余分なバージョンの簿記で自分の時間を浪費します。
継続的にデプロイされるWebアプリケーションの場合、前もってsymverとビルド番号のテーリングを使用してビルド番号を構築する傾向があります。一般的な予想では、番号は意図的な手順で変更されますが、ビルド番号は真の一意のIDです。
ここで行われているように見えるのは、デプロイメントの日と関連するsvnビルド番号をキャプチャすることです：
<div id="svnrev">
rev 2013.10.21.1078
</div>
それが価値があるもののために。
バージョン管理の理論については、ここでもう1つ別の見方をするだけで十分です。
いつバージョン1.0.0に上げる必要がありますか？
メジャーバージョン番号の変更に焦点を当てて説明します。
私の答えは次のとおりです。基本的には、準備が整ったときです。 0.9から1.0への移行は非常に重要です。なぜなら、世間では、ベータ版製品から公式リリースに移行するという認識があるからです。
（ここでは、企業の商用製品であると想定します）。
0.9から1.0に移行する前のいくつかの質問。
組織には、現在のすべてのクライアントに通知する時間がありますか。パーティーを開く。多くのサポートリクエストを取得します。あなたの製品を販売するアカウントマネージャー？など.
はい、私はバージョン管理をマーケティングツールとして見ています。見回すと、基本的には業界標準であることがわかります。
私たちの会社はバージョン2.xから3.0に移行し、素晴らしいパーティーを開き、多くの話題を生み出し、そのためにかなりの数の新しいクライアントを獲得しました。一部のインターフェイスの更新を除いて、バージョン間の違いはごくわずかでした。
他の答えはすでに素晴らしいので、私はそれらの上に追加するだけです。ソフトウェアがリリースされておらず、公開バージョン管理が本当に必要ない場合（非公開バージョン管理はVCSです）、キーワード "[〜＃〜] snapshot [〜＃〜]"を追加しますバージョンの最後に。一部のシステム、特に依存関係管理では、バージョン番号ではなくスナップショットの変更日を比較するという点で、スナップショットをリリースされたバージョンとは異なる方法で処理します。したがって、パッケージリポジトリにv。1.0.0-SNAPSHOT 8amがあり、ローカルの依存性ダウンローダーが7amから同じバージョンを持っている場合、更新されたものをリポジトリからダウンロードします。
上記のように、プライベートバージョン管理はバージョン管理システム（git、svnなど）によって提供されます。