Own repository for TopoToolbox_nolibtt.mltbx

[wschwanghart]

I have trouble linking the TT3 repository to the FileExchange as was foreseen for the platform-agnostic TopoToolbox_nolibtt-release. According to TMW's website, TopoToolbox/topotoolbox3 does not have any publishable releases. This is because it requires release tags that must have the format major.minor.patch.extension (patch and extension are optional). Also version number segments must be less than 6 digits, and alphanumeric versions are not supported (e.g. 1.2-beta). Also, I have not yet gotten to the point where I can decide which mltbx-release is the one mirrored in the FileExchange, and I am not sure whether such choice is actually possible. I wonder whether it may be a viable option to create a repository that mirrors topotoolbox3 (e.g. topotoolbox3-nolibtt) but with all libtt-files stripped off.

It is not possible to use custom add-ons on MATLAB online, and for people make TT3 usable on MATLAB online, we need to take the route via the FileExchange.

[wkearn]

We can make additional releases that use the correct version numbering scheme separate from the automatic releases.

We could do something like pytopotoolbox where a manual release triggers a workflow that builds and uploads the mltbx file. Then we bump the version number in toolboxOptions.m and make a release ourselves. If necessary, we could only upload the nolibtt mltbx at that point. That would, however, mean that release version x.y.z on GitHub doesn't come with libtopotoolbox bindings, and we have to direct users who want libtopotoolbox to the automatic releases.

Is it possible to filter the GitHub releases that get picked up by file exchange? We could do something with the extension version number to label nolibtt releases versus libtt ones: say x.y.z.0 is nolibtt and x.y.z.1 has libtopotoolbox. Or we could use "invalid" version numbers like x.y.z-libtopotoolbox to denote the latter, so they don't get picked up by FileExchange.

[wschwanghart]

It seems like it is not possible to pick up a release by the file exchange. In fact, I am not even sure whether they pick up a toolbox at all, or whether they will compile it themselves. I need to look at it still in more detail. Also, I think I like the idea of going back to the latest-release strategy that we had before, and manually release a new version from time to time. What do you think?

For the nolibtt-version, I think that a viable approach could be to have a separate repository that is just a snapshot of the latest (manual) release. There should be no contributions or other interactions with this repository and it should have a GitHub actions workflow that removes all the binaries.