Comments on: Automatic Build Sub-Versioning in Xcode Official blog of Red Sweater Software Fri, 09 Oct 2015 20:11:22 +0000 hourly 1 By: mkbuild, an iPhone project build script – Whatever happened to Benjamin Ragheb? Mon, 11 Apr 2011 17:56:28 +0000 […] tags and automatically determines the next available build number. I briefly experimented with using the repository revision number, but decided it would be better to decouple the build numbering from the revision control system […]

By: Daniel Jalkut Mon, 02 Apr 2007 15:37:21 +0000 It sounds like you’re using a single subversion repository for multiple projects, and trying to script it so that you get roughly what you would see if you had separate repos for all the projects.

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.

By: Kevin LaCoste Mon, 02 Apr 2007 15:18:29 +0000 I really like the idea of tying build numbers to something concrete/meaningful rather than just making an arbitrary decision to bump the number up now and then. I also believe that the Subversion link is a really good way to go.

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?

By: Daniel Jalkut Sun, 01 Apr 2007 15:36:42 +0000 For the time being I am still using SVN versions or some slight variation on that theme. For instance when I acquired MarsEdit, it was using a different scheme, but one that kept the number quite low. It was I believe the marketing version as a single number, so since I bought MarsEdit at 1.1.2, the bundle version was 112. So from here on the bundle version in MarsEdit is (112 + My Subversion Revision Number).

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.

By: Kevin LaCoste Sun, 01 Apr 2007 11:27:05 +0000 How are you handling this now? After reading through this and experimenting on my own it seems that Subversion revision numbers aren’t the answer after all. Now that you’ve got a handful of serious applications to speak for, have they forced you to come up with a better solution?

By: JM Marino Thu, 29 Mar 2007 09:25:30 +0000 Sorry, I was a bug in my last perl script !!

Try this

By: Taybin Thu, 29 Mar 2007 00:43:06 +0000 Here’s the system I’ve ended up using:

My Info.plist contains this:

${CURRENT_PROJECT_VERSION} (build: $Revision$)

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?

By: Taybin Wed, 28 Mar 2007 23:58:35 +0000 Possibly an even better way to get the SVN revision number:

By: Taybin Wed, 28 Mar 2007 20:29:06 +0000 Oh, 123[BUILD] is much better than my setup. [yoink]

By: Daniel Jalkut Wed, 28 Mar 2007 20:15:22 +0000 Ah thanks. Fixed.

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.