The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.
This document is licensed under The Apache License, Version 2.0.
When using the name 'version' we mean the versioning scheme described in VERSIONING.md
This document is to describe the release pipeline, which is taking the result of the artifacts created according to BUILDING.md and publish a release to the various release targets for the project.
We propose:
- a set of release targets that are allowable
- a pipeline for handling the release folder's artifacts
It is NOT the purpose of this document to describe how a project might create a build, NOR is it describing a strcture in which projects MUST write build artifacts to. It is describing the structure of the releases themselves.
Process is outlined in BUILDING.md
- Clean the build directory
- run:
bin/build.{target}.{ext}
Projects SHOULD automated the version bump following CONVENTIONAL_COMMITS.md.
Projects SHOULD use generated changelogs from following CONVENTIONAL_COMMITS.md.
A project MUST generate a commit with the changes.
A project MUST be tagged with the semantic versioning scheme from VERSIONING.md.
- MUST be a pgp signature
- MUST be the same pgp key as is registered with Github
- MUST be a detached ascii-armored (.asc) signature
- All files in the build folder MUST have an associated signature file
For each of the desired release targets, prepare and push the release.
- Github
- Docker Hub
- semantic-release
- [Conventional Commits](https://conventionalcommits.org/