Last week Connor McDonald tweeted that he received the following question on AskTom: “I hacked the Apex install scripts to get access to the APEX… schema..and now Apex doesnt work“ The community had a few reactions on twitter including my comment which stated that “They’re some cases where it’s good. I use it to “inject” the version as part of the build process.“
I had mis-read Connor’s statement and interpreted “hacked the APEX install scripts“ as “hacked an application install script“. To correct my statement, you should NEVER modify the main APEX installation script. That said, I usually modify an application’s install script despite the fact that I shouldn’t. I have a good reason though which is described below.
Each APEX application has a meta data property called
Version and is usually displayed in the bottom of most applications by referencing the substitution string
APP_VERSION in the page’s template as shown below.
The application’s version is statically defined in the application’s properties which can be set in Shared Components > Application Definition:
Since the properly must be statically defined it requires a manual step to update the version number each time the application is released. This usually requires someone to update this value before exporting the application for each release. Personally I’m not a fan of this as I try to automate as much as possible for each build and it can easily lead to mistakes.
To get around this I use a mnemonic string as the release version and replace it using a script as part of my build process. Here’s an example.
Change the version number to
The export file will now look like:
You can now use a command like
sed in Linux or Node.js to find and replace
%RELEASE_VERSION% with your build release version. An example of a build script that both exports the application and sets the version number:
set termout off