Script applets and bundles, like any other applications and bundles, support version numbers and build numbers, and the ability to set them has been part of Script Debugger for a long time. Script Debugger 8 expands on that support.
Before looking at the changes, here’s some background on how they are typically used.
You can see the version of an applet or bundle by choosing Get Info in the Finder, making it simple for anyone to check.
The first point to be aware of is that the version is not actually a number — it, and the build number, are strings. As such, they can theoretically contain just about anything. In practice, though, they should follow certain established conventions.
For versions, the convention is that they consist of up to three dot-separated numbers. The first number is known as the major version number, the second as the minor version number, and the third as the patch version number. The patch number is often dropped if it would otherwise be 0, whereas a minor version number is usually always included. So when you create a script applet, it has a version of “1.0”.
Although the convention is to use just numbers, it is not unknown to also use other characters — a beta version might be called version “1.1.1b1”. But even is such cases, there’s generally a trailing digit or digits in each field.
Of course, there are exceptions. Some applications have version “numbers” that include things like release dates and other information. You can use what you’re comfortable with. But the new features in Script Debugger are built around the conventions.
The build number is not displayed so prominently. It appears in a standard About… box, in parentheses after the version number, but you can’t generally access the About… command in script applets unless they are saved as stay-open. You can always display it in a script yourself if it matters, for example in a dialog title. But often build numbers are of more interest to the script author, as a way of tracking when changes were made.
Build “numbers” often also contain non-digit characters, but generally they end with a number, which is often incremented even when the version number is not.
In previous versions of Script Debugger, the version and build number were set in the Resources tab, and could therefore only be set for applets and script bundles. In Script Debugger 8 they are set in the File -> Bundle & Export Settings dialog. This means they can also be set for compiled scripts and text files. In such cases they are saved as metadata only, so are not accessible via the Finder’s Get Info command — but they are used if you export or save as an applet or bundle from those files.
Script Debugger has also had an option to have the build number automatically increment every time you save (this assumes your build number is in a format that can be incremented, with a trailing numeric value). Script Debugger 8 adds a new option: to instead increment each time a script is exported. (Because changing the build number modifies a document, you need to save after exporting if you choose this option.)
You select either option, or manual incrementing, in the Bundle & Export Settings dialog, where there is also a stepper control to manually increment/decrement the value. The version number field has been split into three fields, for the major, minor, and patch numbers. There is no need to enter dots.
There is also a new Version submenu in Script Debugger’s File menu. The first two items do nothing other than display the active document’s version and build number. The next four commands increment the build number, major version number, minor version number, and patch version number, respectively. They also display the updated versions in the status bar, if it is showing.
If automatic incrementing of the build number is turned off, incrementing the build number using one of the Version submenu commands will also increment the build number.
The increment commands rely on the numbers following convention, with a trailing number to increment. When a minor version number is incremented, any patch number is discarded. When a major version number is incremented, the minor version number is set to 0 and any patch number is discarded.
Here are samples of versions and how they are increment by the commands:
| Version | Increment Major # | Increment Minor # | Increment Patch # |
|---|---|---|---|
| 1 | 2.0 | 1.1 | 1.0.1 |
| 1.0 | 2.0 | 1.1 | 1.0.1 |
| 1.0.1 | 2.0 | 1.1 | 1.0.2 |
| 1.0.1b1 | 2.0 | 1.1 | 1.0.1b2 |
| 1A.0 | 1A1.0 | 1A.1 | 1A.0.1 |
Build numbers increment similarly:
| Build # | Incremented Build # |
|---|---|
| 1 | 2 |
| 1.0 | 1.1 |
| 1.1 | 1.2 |
| 1A | 1A1 |
| 1A1 | 1A2 |
One slightly confusing aspect of these numbers is that for applets and bundles they are stored in the bundle’s Info.plist file, and when Script Debugger opens an applet or script bundle, the operating system caches the contents of this file, and the contents in memory cannot be modified.
So let’s say you have a new applet open in Script Debugger and you run this code:
display dialog (my version)
It will display “1.0”. If you now increment the version number and save, when you run the script again, you will still get the cached result of “1.0”. But if you run the applet itself, or choose Get Info on the file in the Finder, you will see the updated version. To get the correct version using this code in Script Debugger, you will have to quit and relaunch after making the change. (The same applies to all the Info.plist entries.)
Getting the build number via script is more complicated, and requires the use of AppleScriptObjC:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions
set theApp to path to me
set theBundle to current application's NSBundle's bundleWithURL:theApp
set buildNum to theBundle's objectForInfoDictionaryKey:"CFBundleVersion" -- yes, that's the correct key
if buildNum is not missing value then set buildNum to buildNum as text