As consumers, we like to get a binary release in one of the following ways:

OS native package format such as deb , rpm and so on.

, and so on. Language native package format such as pip , npm and so on. It's not common to supply a pure binary artifact this way but some do it, such as puppeteer which downloads a latest binary of a headless Chrome.

, and so on. It's not common to supply a pure binary artifact this way but some do it, such as puppeteer which downloads a latest binary of a headless Chrome. A curl shell combo such as curl http://acme.org/bin | sh which is fast, has no dependencies, but receives criticism because you're essentially letting your users execute remote code. This is why I avoid these, but if I must, verify the shell script by hand first.

which is fast, has no dependencies, but receives criticism because you're essentially letting your users execute remote code. This is why I avoid these, but if I must, verify the shell script by hand first. A modern binary packager such as Homebrew.

While the process may differ from one technique to another, they all require a way to host the binaries or packages, except perhaps the language-native package formats, where you can get away with pushing large binaries into the registries (but it may be frowned upon).

In principle, these are the steps required do package and release:

Cross compile your binaries (e.g. Linux, Windows, macOS), since we’re distributing binaries we have to have a ready-made version per platform and architecture. Package (e.g. tar, zip), some platforms expect a specific packaging format. Digest your packages (e.g. sha256) — while we’re all enjoying a reliable internet connection and file hosting solutions — we’re not assuming it’s always the case for all users. It’s wise to verify downloads by having it digested. Upload to <provider> using some kind of path format scheme (e.g. to S3 as `v0.0.1/project-name/tarball). Set up the distribution artifact (e.g. generate a shellfile for download and verification from S3 using the given format scheme).

For an open source project, there are many tools to use, because Github Releases and Git tags make it a breeze to construct a great release process. For other projects, Amazon S3 would be perfect for storing, and an opinionated release formatting rules helps. This is where GoReleaser shines.

Using GoReleaser with Rust

Although GoReleaser supports building just Go projects, it does so much more in the packaging and distribution department that it is extremely hard to ignore.

It can package, generate sha256 sums, upload to Github releases or Amazon S3 or custom HTTP endpoints, as well as generate a changelog, semantic versions and a lot more. The website doesn’t show everything, so I recommend looking at the repo for docs and to find out what more it can support.

So it has everything we want, but it can’t build anything other than Go.