With larger scale projects and applications, bug and issue tracking is an important and often essential part of the development process.
Without it, issues can be forgotten or smoothed over and the end product will suffer.
It also provides options for issue prioritisation and the ability to perform phased releases, which gives a instant and clear view of exactly what issues are fixed and what are not in any single release.
This can be invaluable when communicating with clients as it is easy to get an overview of progress (if development tasks are also itemised in the issue tracker) and whether any new features are feasible given the outstanding issues. It is also an absolute necessity when working alongside testers, who will need to know exactly what is fixed in the version they are testing..

This is all well and good as long as you know beyond a shadow of a doubt which version of the release you’re dealing with – the developer has built the correct code; the correct version is on the server; the tester/client/PM looking at the SWF has cleared their cache…

There are so many ways to fail here and the easiest way to avoid this is to add a build number to the right-click menu so that anyone can quickly see what version of the file they are looking at.

I’ve seen companies in the past that pass build version numbers into the flash via flashVars, but all this really does is provide the version of the HTML file – not the version of the SWF file. I’ve actually seen a day or two of testing work wasted because the build number in the HTML had been incremented, but the new SWF had failed to copy across. The testers were under the impression that they were looking at the latest build and ended up marking all the issues as “not fixed”.

You’ll notice right-click build info around the web. It’s on YouTube, iPlayer, Vimeo and other large scale applications and I can imagine that on those applications, having baked-in version info is paramount.


Adding a right-click menu item is the easy bit:


The hard bit is actually getting a build number actually hard coded into the SWF and for this, the simplest method is to use an ANT build file. All the main flash IDEs support ANT and although sometimes you may need to download extra packages in order to enable certain features, everything you need should be there already. If you need help getting an ANT build setup, then check this good example here.

The idea is that you define a compiler option that will hold the build info and then use that in your code:

…and inside your ANT build file’s MXMLC task:

Note: the value must be quote delimited or it will fail..


The last part is to increment the build info automatically and the simplest way to do that is to hook into your source control system (SVN/GIT).
Getting the latest revision number from your source control is relatively easy and there is even a dedicated ANT package for working with SVN – SVNANT. The idea is to simply execute your source control executable and parse the info given.

Note: your executable must be available to run from your ANT file’s location.

I only have GIT installed on my machine at the moment, so will use that as an example. With GIT, the best practise is to tag releases as you go in order to update the build. You can then use describe to pull out the latest tag.

Make sure the target that contains your MXMLC task ‘depends‘ on the getGitRevision task as any targets defined in the ‘depends’ param will be executed before running the current target.