Database Reference
In-Depth Information
Include the Build Number Directly into the Application Version
Eventually, you're going to get a bug report, and after spending hours trying to repro-
duce it, you may learn that the user was running an old build. Grrrrr! Wouldn't it be
great if we could automatically bump up the minor version number of the application
every time we did a build? Well, Bunky, you're in luck! It turns out that with a few
magic steps, you can do just that.
The first step is the simplest of all, you just need to put a string in your version number
(and short version number) in your
applicationname
-info.plist
file, something unlikely
to occur anywhere else in the file. I like to use BUILDNUM in all caps. So, if your version
number for your application is 1.0, you'd use
1.0.BUILDNUM
as the version number for
the two properties in the plist (see
Figure 3-10
).
Figure 3-10. Editing the plist version number
There's only one more step we need to take here, which is to tell Hudson to run a small
shell script, which will replace the
BUILDNUM
string with the actual build number (which,
helpfully, Hudson exposes as an environment variable to shell scripts it runs).
Go back into the configuration for our build, and create a new build step (in the same
way that we created the Ant build step earlier). But, this time, rather than selecting
Invoke Ant, select Execute Shell. You'll end up with a text box directly beneath the
existing Ant target text box. Before we do anything else, grab the step by the little grey
box “handle” on the left, and drag it above the Ant step, because we want to edit the
plist entries before the build runs.
The script itself is trivial, and is shown in
Example 3-3
.