Issues with Add-On Versioning

I am making updates to one of my File Exchange add-ons, and the updates will require an updated version of another add-on. The state of versioning for add-ons seems to be a bit of a mess.

First, there are several sources of truth for an add-on’s version:

• The GitHub release version, which gets mirrored to the File Exchange version
• The ToolboxVersion property of toolboxOptions (for an add-on packaged as a toolbox)
• The version in the Contents.m file (if there is one)

Then, there is the question of how to check the version of an installed add-on. You can call matlab.addon.installedAddons, which returns a table. Then you need to inspect the table to see if a particular add-on is present, if it is enabled, and get the version number.

If you can get the version number this way, then you need some code to compare two semantic version numbers (of the form “3.1.4”). I’m not aware of a documented MATLAB function for this. The verLessThan function takes a toolbox name and a version; it doesn’t help you with comparing two versions.

If, however, add-on files were downloaded directly and added to the MATLAB search path manually, instead of using the .mtlbx installer file, the add-on won’t be listed in the table. You’d have to call ver to get the version number from the Contents.m file (if there is one).

Frankly, I don’t want to write any of this code. It would take too long, be challenging to test, and likely be fragile.

Instead, I think I will write some sort of “capabilities” utility function for the add-on. This function will be used to query the presence of needed capabilities. There will still be a slight coding hassle—the client add-on will need to call the capabilities utility function in a try-catch, because earlier versions of the add-on will not have that utility function.