# Releases

A release consists of:

- A full set of `isle` binaries for all supported platforms, compiled from the
  same source.
- A text file containing hashes of each binary.
- A file containing a signature of the hash file, created by whoever is building
  the release.

Releases are named using semantic versioning: <major>.<minor>.<patch>. A
preceding "v" is NOT a part of the canonical release name, though it use used in
specific contexts.

Release artifacts are also be labeled with a suffix indicating build number, eg
"0.1.3-2" which indicates that this is of release "0.1.3". The first build of a
release is always "1". Different build numbers of the same release indicate that
no code is different, only the packaging.

## Building

*NOTE: This has only been tested from an x86_64 linux machine*

To create a release only a functional nix installation is required. Simply run
the `./release.sh` script, providing the release name and build number.

From here an `isle` binary will be cross-compiled for all supported
platforms. This will take a long time the first time you perform it on your
machine.

Once compilation is completed, the release will be signed using the default GPG
key on your machine, and you will be prompted for its password in order to
create the signature.

## Releasing

Release artifacts are hosted at `micropelago.net` under
`/isle/releases/v<release name>`. An `index.gmi` page should be created in that
directory which includes links to each artifact, as well as a changelog
detailing all new features and fixes included since the previous release.

A link to the new release should be included at `/isle/releases/index.gmi`.

Each release should be tagged in the git repo using the release name and build
number prefixed with a "v". If the build number of the release is "1" then the
tag notes should link to the `micropelago.net` release page for the release.