This PR holds automation for source and binary releases of the SDK whenever a version tag is applied. It only creates a draft release which then has to be manually verified and published. (The UI is fairly straightforward) A draft release which runs after adding a version tag look like this.
Currently only Windows binary releases are done, because that is the platform which necessitates this the most, but later iterations can expand on that. (I would call on people actually shipping Linux releases, not just libraries to tune in on what is the optimal set of release build flags on Linux.) Submodule source files are included in the source tarballs.
(Unfortunately I can't remove the automatic source tarball assets, those are always added by GitHub and can't be removed. I already reached out to the community if that's possible, but that is more or less polish atop the feature. It's important, we don't want people downloading the wrong stuff, but there's really no way around it, or not that I know of.)
This PR holds automation for source and binary releases of the SDK whenever a version tag is applied. It only creates a draft release which then has to be manually verified and published. (The UI is fairly straightforward) A draft release which runs after adding a version tag look like this.
Currently only Windows binary releases are done, because that is the platform which necessitates this the most, but later iterations can expand on that. (I would call on people actually shipping Linux releases, not just libraries to tune in on what is the optimal set of release build flags on Linux.) Submodule source files are included in the source tarballs.
(Unfortunately I can't remove the automatic source tarball assets, those are always added by GitHub and can't be removed. I already reached out to the community if that's possible, but that is more or less polish atop the feature. It's important, we don't want people downloading the wrong stuff, but there's really no way around it, or not that I know of.)