Issues with Add-On Versioning

General
팔로우


Issues with Add-On Versioning

Steve Eddins 2025년 2월 13일 15:29
최근 활동 Michelle Hirsch답글: 2025년 2월 20일 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
참여하려면 로그인하세요
Michelle Hirsch
Michelle Hirsch 2025년 2월 13일 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 2025년 2월 13일 16:18

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

Bjorn Gustavsson
Bjorn Gustavsson 2025년 2월 20일 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 2025년 2월 20일 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
게시물s
42
답글s
19
팔로워

태그

아직 태그를 입력하지 않았습니다.

Go to top of page