APIやソフトウェアのライブラリを開発する際にバージョン管理をすることが多いと思います。
バージョン番号のルールを決める際に参考にしたいのがセマンティック バージョニングになります。
以下概要です。
バージョンナンバーは、メジャー.マイナー.パッチ とし、バージョンを上げるには、 1. APIの変更に互換性のない場合はメジャーバージョンを、 2. 後方互換性があり機能性を追加した場合はマイナーバージョンを、 3. 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。 プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチ の形式を拡張する形で利用することができます。
さらに詳細を見ていくといくつか気になる点があります。
特にバージョン番号を拡張する識別子、ビルドナンバー（ビルドメタデータ）は使った方が問題が発生した際に調査がしやすくなると思います。
セマンティック バージョニングを適用するソフトウェアはパブリックAPIを宣言しなければなりません（MUST）。
これは外部のアプリケーションやライブラリが使用する機能のことと理解ができるようです。パブリックなWEB APIを作る必要があるわけではありません。
メジャーバージョンのゼロ（0.y.z）は初期段階の開発用です。
これは既に本番稼働している場合はバージョン1.0.0以降からつける必要がありそうです。本番リリース前はゼロから始まるバージョンで管理するということだと思います。
プレリリースバージョンは、パッチバージョンの直後にハイフンとドットで区切られた識別子を追加することで表現してもよいです（MAY）。例：1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92。
本番リリース前のalpha版beta版以外にもrc(Release Candidate)といった命名も当てはまるようです。
ビルドメタデータはパッチまたはプレリリースバージョンの直後にプラス記号とドットで区切られた識別子を追加することで表現してもよいです（MAY）。例：1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85。
これはビルド時の識別子のようです。ビルドした日時などを使うのが良さそうですね。
普段なんとなくバージョン管理をしているケースもあると思いますので、その場合は上記を参考にもう少しルールを明確にすると開発時のコミュニケーションが円滑になるかもしれません。
参考リンク：
セマンティック バージョニング 2.0.0 | Semantic Versioning
