micropelago/isle
4
1
Fork 0
Code Issues 1 Pull Requests Projects Releases 6 Activity
0a2bad11f6
isle/docs/dev/releases.md

1.9 KiB
Raw Blame History

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: ... 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.