Issues with Add-On Versioning
Steve Eddins
on 13 Feb 2025 at 15:29
Latest activity Reply by Michelle Hirsch
on 20 Feb 2025 at 17:45
General observations on practical implementation issues regarding 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 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 returned by matlab.addon.installedAddon. 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.
I also posted this over at Harmonic Notes
4 Comments
Sign in to participate
Hopefully we can straighten this out over time with the move to packages (e.g. mpackage.json) introduced in R2024b. Version is a reasonably first class aspect of packages and package dependencies. Version resolution is handled at install time (by mpminstall), so at least in theory you shouldn't have to write code to verify the correct versions of the correct libraries are available.
It will take some time to get there, though. We need to get to the point where the File Exchange can function as a public MATLAB package repository.