I personally use separate repos, though I’ve often considered consolidating them.

Your post gave me an idea though, that would address the problem I alluded to with the “branches more up to date than later revisions” problem. You just have to build in “buffer space” in the versioning scheme between major releases, to accommodate any ongoing branch work that might happen.

For instance if I ship 1.2 with svn revision #138, then when I go to work on 2.0, I might start the CFBundleVersion at “200 + svn”. Then I would have the flexibiliity to make a reasonably large number of releases on the branch, and change the versioning strategy for the branch to no longer use the subversion number.

It loses a lot of elegance, but at least it does work around the problem. If branched releases are relatively uncommon, this seems like a reasonable workaround.

My current thinking is to have a script that runs a log command using a range. The script could then count the number of checkins between the last release and the current release and use that value to increment the build number. If you commit changes to the repository every time you fix a bug or add a new feature then you end up with a reasonably accurate build number for each new release. That Subversion command would be something like:

svn log -r38:HEAD

As an example, I have a new project in my repository and I can see that the revision number is at 40 while the actual number of checkins for the project is only 16.

Any thoughts on this approach? Or better yet, any takers for whipping together the necessary scripts?

The issues that have been raised with using the revision number have to do with complications that might arise from using the same repository to generate different versions of the app. For instance if I branch for 1.1.8 after releasing 1.2 of MarsEdit, then it will have a higher bundle version and therefore be perceived as “more up to date” than the 1.2.

I have considered moving to a more robust scheme that takes things like this into consideration, but I haven’t bothered yet. Simply knowing about the limitation has been enough for me.

Try this

My Info.plist contains this:

CFBundleVersion
${CURRENT_PROJECT_VERSION}.$Revision$
CFBundleGetInfoString
${CURRENT_PROJECT_VERSION} (build: $Revision$)
CFBundleShortVersionString
${CURRENT_PROJECT_VERSION}

My Update Version script is essentially reduced to:

$info =~ s/\$Revision: (.*) \$/$1/g;

The idea is that the revision number is considered a submicro version.

This fixes the problem of stable branches because the macro version number will have priority. And the CFBundleShortVersionString has the marketing number which ignores the build version entirely.

Any comments?

Taybin: it looks like he’s added facility to template the injection of the number in the Info.plist. So instead of completely replacing the CFBundleVersion, it just injects the number into the part that is labeled “[BUILD]” … so you can have CFBundleVersion set to “123[BUILD]” and if your svn version is 45 it will come out in the resulting app as “12345″.

By the way I realized I’m assuming JM is a male. Apologies if this is incorrect.