Tags

,

Maintaining versions of source code is always a challenge. In the enterprise, we use version control systems, but managing multiple versions is not an easy task.

While developing applications on my own, I use the convention of adding version numbers to the directory and making a directory copy before advancing the version number. I know that this is the crudest method possible, but I am using it as I am undecided about installing a version control server on my home computer.

While naming, I use the ‘major.minor.build’ convention. The major number is incremented only if there is a significant change to the application behaviour, look-and-feel, etc. Minor numbers are supposed to change for bug fixes, while build numbers are supposed to change for each build. But build number is not changed automatically (though easily rectified by using an appropriate Ant ‘build.xml’).

The problem is aggravated when making apps for Android. Earlier, I did not give much weightage to the ‘versionCode’ field of the Android Manifest file. Recently, when I wanted to uploaded a new version of the application to the Android Market, the version number created a hurdle. Though I had incremented the version number as per my convention, Google market does not understand it. It seems to treat the version number as a piece of text to be ignored. While doing so, it attaches importance to the versionCode. Hece, I had a new app that has a new version numebr, but the same version code. Google did not accept the apk file till I incremented the version code.

I have had to rethink the version numbers I have been assigning to application directories. While the version code is simply incremented, I try to keep it sync with the ‘major.minor’ number combination. The only problem I will face it this – 1.2 is the same as 2.1.

Advertisements