Issues with Add-On Versioning

General
Follow


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
Sign in to participate
Michelle Hirsch
Michelle Hirsch on 13 Feb 2025 at 15:44
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.
Steve Eddins
Steve Eddins on 13 Feb 2025 at 16:18

Thanks, Michelle. I’m looking forward to seeing File Exchange support.

Bjorn Gustavsson
Bjorn Gustavsson on 20 Feb 2025 at 15:48
Isn't this a problem similar to the ones we can cause with inheritance-confusion in object oriented programming? If my add-on function depends on two other add-on tools that possibly depend on a common third add-on, and then when that third one is modified such that additional modifications in the first two add-ons are required to be up-to-date and only one of them are updated - wouldn't that be "challenging" to handle automatically? (reply mainly for me to get notifications about continued discussion and solutions(?) to this problem...)
Michelle Hirsch
Michelle Hirsch on 20 Feb 2025 at 17:45
Yes, there's nothing a package manager can do to help with this specifically, other than doing the best it can to find a compatible version of all dependencies. For your specific example, since the latest versions of the three dependencies aren't compatible with each other, you would specify your add-on dependencies to the older versions of the two direct dependencies. You wouldn't get any new capabilities, but your add-on won't be broken by the updates.
The thorny part is when you get into the combinatorics, if your users use another Add-On that actually requires the new versions of the two updated dependencies. This is often what people refer to when they reference "dependency hell" with Python, when it becomes impossible to find and maintain a fully compatible set of libraries for your stack.
Steve Eddins
Retired from MathWorks in 2024 after 30 years of service. Can now be found at MATLAB Central and steveeddins.com. MathWorks career included image processing, toolbox development, MATLAB development and design, development team management, MATLAB desi...
5
Posts
42
Replies
19
Followers

Tags

No tags entered yet.

Go to top of page