To allow multiple lines of development and release we go back to the old days of Basic line numbers. The order below is by release date:
10000 1.0-0
10001 1.0-1
10002 1.0-2
10100 1.1-0
10103 1.1-3
10200 1.2-0
20000 2.0-0
10201 1.2-1
The above limits one to 100 dot and 100 dash releases at each level (2 digits). One could use 10 per level (1 digit) but I have never worked with "real" software that would live within that restriction. Given today's constant integration methodology there are even some cases where 1000 (3 digits) would be needed per level.
Using 2 digits provides 31 major releases for signed 16 bit integer or 63 for unsigned. This should/may give the Android world enough time to go to 64 bits if need be.
This method provides for multiple branches, that can be examined by programs, with the higher versionCode numbers meaning upgrades from lower numbers.
Versioning Your Applications states:
Other applications ... need to query
the system for your application's
version, to determine compatibility
and identify dependencies
android:versionCode — An integer value
that represents the version of the
application code, relative to other
versions
The value is an integer so that other
applications can programatically
evaluate it, for example to check an
upgrade or downgrade relationship. You can set the value to any integer you want,
however you should make sure that each successive release of your application uses a greater value.
The issue remaining is regarding "each successive release". Is this intended to restrict one to the date of so that you cannot have both 1.2-1 and 2.0-0 succeed 1.2-0 except when the release dates are in that order. versionCode values: 10200, 10201 & 20000 provide for an "upgrade or downgrade relationship". Or is the use of an integer value intended to limit one to a single line without branches?