This PR follows essentially the same process as what we've followed for OSQP release.
On creating a release in the osqp-matlab repo (without the v prefix, e.g. 0.6.3), the release workflow will call package_osqp, but with a new optional argument (the tag obtained from the action). The resulting build folder will have the version/platform in its name (e.g. osqp-0.6.2-matlab-linux64, but the .tar.gz will not have the version in its name (e.g. osqp-matlab-linux64.tar.gz), but will of course still expand to a folder with the version name. This is to allow install_osqp.m to just refer to something like:
The workflow will auto-generate osqp-matlab-linux64.tar.gz as a release asset. For Windows and Mac, manually-generated osqp-matlab-<platform>64.tar.gz files can be added as assets to the release after this workflow is complete (Release -> Edit -> Upload files')
This PR follows essentially the same process as what we've followed for OSQP release.
On creating a release in the osqp-matlab repo (without the
vprefix, e.g.0.6.3), thereleaseworkflow will callpackage_osqp, but with a new optional argument (the tag obtained from the action). The resulting build folder will have the version/platform in its name (e.g.osqp-0.6.2-matlab-linux64, but the .tar.gz will not have the version in its name (e.g. osqp-matlab-linux64.tar.gz), but will of course still expand to a folder with the version name. This is to allowinstall_osqp.mto just refer to something like:to get the latest file.
The workflow will auto-generate
osqp-matlab-linux64.tar.gzas a release asset. For Windows and Mac, manually-generatedosqp-matlab-<platform>64.tar.gzfiles can be added as assets to the release after this workflow is complete (Release -> Edit -> Upload files')This workflow works just fine in my tests.