Skip to content

Latest commit

 

History

History
37 lines (22 loc) · 2.18 KB

releasing.adoc

File metadata and controls

37 lines (22 loc) · 2.18 KB
Raw

Releasing a new version

This document describes how to release a new version of ODS pipeline.

Versioning Scheme

ODS pipeline follows Semantic Versioning 2.0.0. This means breaking changes need a new major version.

Release Process

Before starting the release process

Ensure that all issues with the milestone of the release are resolved (or re-assign the issues to a future release). Further, run govulncheck ./…​ locally to check if there are any vulnerabilities that need to be fixed before the release. For more information on govulncheck, see https://go.dev/blog/vuln.

Preparing the release

The current version is hardcoded in a few places across the repository. All of these places must be updated for a release (search for X.Y.Z, ignoring the test directory). After the version numbers have been updated, mark the new version as released in the changelog and update the readme file. Commit the changes and push to the main branch.

Publishing the release

Draft a new GitHub release, creating a new tag in the process (e.g. v0.2.0). The description should be like this:

< Note highlights of the release and any breaking changes >

For all changes and more details, please see the [changelog](https://github.com/opendevstack/ods-pipeline/blob/main/CHANGELOG.md#< Add anchor of the released version>).

To update your ODS pipeline installation, refer to the [update instructions](https://github.com/opendevstack/ods-pipeline/blob/main/docs/installation.adoc#updating).
Note
 When a Git tag is created, container images are built automatically and pushed to ghcr.io.
Note
 Do not attach binaries yet, this should be done after the release is published.

Attaching binaries to the release

The artifact-download binary should be offered as a pre-built binary for linux/amd64, darwin/amd64, darwin/arm64 and windows/amd64. These can be generated via make build-artifact-download, and then uploaded in the GitHub release creation form.

Note
 Ensure to pull before running the make target so that you have the created Git tag available locally. Building from the Git tag ensures that the version information in the binary is correct.