This is on my to-do list for the runtime. It's something that we're
doing with other projects and it means that the release process is just
creating a tag. This then builds releases for any targets that we want
to ship binaries for, creates the GitHub release, pushes the built
artefacts to the release, and adds a new commit on the main branch
rolling over versions and so on.
David
There’s the GPG signing part that makes Github Actions less useful. That is: whether you want to use Github actions depends on where you want to store this rather secret key. (We should rotate the GPG key anyway, by the way; the one we use for gnustep make/base/gui/back is still a 1024 bit key, with no delegation to subkeys and no expiration dates set.)
Besides, making the tarballs themselves is the easiest part.
For the make/base/gui/back stuff, the hardest for me was going through the history, trying to make sense of everyone’s rather cryptic commit messages and rather lacking ChangeLog updates, identifying and summarizing the changes into something that might be useful to a reader, putting the changes into 2 different places, then generating the new release notes file.
If I recall correctly, I touched up gnustep-make so invoking the magic git release commands will produce the correct annotated tag containing the release notes file as the tag’s commit message (meaning I have no need to do anything on Github releases page to make this text show up).
But at that point, building the tarballs and signing them is easy. Uploading them to Github is just a drag and drop. Uploading them to FTP (…and I really need to sit down and bring it up on the ‘new’ DigitalOcean machine, but in a more secure way than using a password over unencrypted FTP) is easy. Writing release notes and dealing with GPG’s rejections of the passphrase on the key is difficult.
I never fully completed the work on our own Debian packages so there’s no point in having Github Actions for that particular purpose. Besides, Debian ‘source’ packages also need to be GPG signed. (Note, I am not talking about the code we want to upstream into Debian proper; this would be ‘our’ packages, built with libobjc2 and clang, and preferring ‘steppiness’ over FHS. It was not to be about making them better than Debian-built packages, but about providing a different experience. And maybe adding a ‘defaults’ package that configures a different theme and such.)
What about win32? I never built win32 releases with NSIS, either. There have been improvements on building .msi packages on free platforms (GNOME’s msitools have gotten some GUI support!), but last time I checked, it was still not sufficiently similar to WiX Tools on Windows.