書いている人
モバイルアプリケーションアーキテクトとして働いています。モバイルアプリケーションのアーキテクチャ、自動テスト、CI/CDに興味があります。
Androidアプリのバージョン番号を X.Y.Z 形式、いわゆるセマンティック・バージョニングにすることは必須ではありません。Androidではバージョン番号の指定を versionName で行いますが、 versionName は文字列でありさえすれば問題ありません。なのでバージョン番号の命名は好きにしたらいいんですが、セマンティック・バージョニングを採用するメリットも確かにあります。
バージョン番号を メジャー.マイナー.パッチ とするバージョニングのルールです。互換性のないアップデートでメジャーを、互換性があり機能が追加されるアップデートでマイナーを、後方互換性を伴うバグ修正でパッチを、それぞれインクリメントしていきます（セマンティック バージョニング 2.0.0 | Semantic Versioning）。
Androidアプリのユーザーが上記リンクに示されるようなモチベーションを感じることは稀だと思いますので、Androidアプリ開発においてセマンティック・バージョニングを導入する必然性は薄いと思われます。メリットがあるとすれば、ユーザーではなく開発者の側でしょう。
すなわち、「次のアップデートはメジャーアップデートだから、メジャー番号を上げたバージョンをリリースしよう」とか、「プロダクションにバグがあるからhotfixを出そう、パッチ番号を上げたバージョンをリリースしよう」というような場面では、セマンティック・バージョニングを用いることで開発者内のコミュニケーションを円滑にできる効果があると思います。
versionName と versionCodeAndroidアプリには、ふたつのバージョンが存在します。前述の versionName と、 versionCode です。
versionName が文字列であったのに対し、versionCode は正の整数で、内部的なバージョン番号として使用されます。Google Playでは versionCode を用いてアプリのバージョン管理を行なっており、端末にインストールされているアプリの versionCode よりも小さな versionCode を持つアプリを端末にアップデート・インストールすることはできません。
versionCode については、最初のリリースで 1 を設定し、リリースごとに単純に値を増やしていくというのが最もあり得る運用であると思います。 versionCode まで頑張ってセマンティックにはしないということですね。
一般的に、アプリの最初のバージョンをリリースするときは versionCode を 1 に設定し、リリースを重ねるたびに、メジャー リリースかマイナー リリースかにかかわらず、単純に値を増やします。つまり、versionCode 値は、ユーザーに表示されるアプリのリリース バージョンを必ずしもなぞっているわけではありません。アプリと公開サービスでは、このバージョン値をユーザーに表示するべきではありません。（アプリのバージョニング | Android Studio | Android Developers）
その他、バージョン番号 X.Y.Z に対して versionCode を 10000 * X + 100 * Y + Z というように決め、 versionName と versionCode を連動させるように決めているプロジェクトもあるかと思います。 versionCode まで頑張ってセマンティックにするパターンです。
この場合は、内部テスト版の配信・アップデートで versionCode を増やす場合を考慮して versionCode のルールを設計しておかないといけません。例えば、下1桁や下2桁を内部テストのアップデート用に取っておく、とかです。つまり、 1000000 * X + 10000 * Y + Z * 100 + 内部テスト用 みたいなルールですね。ちょっと煩雑になってしまいますね。