views:

388

answers:

2

Versioning Your Applications on the Adroid developers web site:

you would release the first version of your application with versionCode set to 1, then monotonically increase the value with each release, regardless whether the release constitutes a major or minor release.

That is all nice and well but how is one to handle this sequence?:

1 1.0
2 1.1
3 1.2
4 1.3
5 1.4
6 2.0
? 1.5
+3  A: 

I presume by that sequence you are really trying to say "what if we want to release a next-generation-tech 2.0 but then still issue a 1.5 patch release against the 1.0 series tech?"

Your choices are:

  1. Don't do that -- once you cut over to 2.0, stay on the 2.0 series
  2. Release the 2.0 tech line as a separate app, perhaps starting over its sequence with 1
  3. Ummmm...there is no #3

My guess is you'd want #2. After all, by definition, you are saying there are two current editions of the app (1.5 and 2.0), and therefore there are, in effect, two different apps.

CommonsWare
A: 

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?

C.W.Holeman II
"then monotonically increase the value with each release"Bear in mind that your solution violates the above principle, insofar as people with 10200 will be prompted to upgrade to 20000, and nobody who moves to 20000 will ever receive 10201 as an option.If you want to have multiple concurrent products, make them multiple concurrent products, and create separate apps for the 2.x series than the 1.x series.
CommonsWare