Skip to content

Latest commit

 

History

History
101 lines (62 loc) · 4.81 KB

Release Process.md

File metadata and controls

101 lines (62 loc) · 4.81 KB

Release Process

The release process for a new version can roughly be divided into the following steps:

The process builds on the Development Flow which, usually, takes place within forks and leads to merged pull requests in the repositories of the eclipse-tractusx organization.

For assigning and incrementing version numbers Semantic Versioning is followed.

Preparations on the release branch

Checking out from the main branch a release branch (release/{to be released version} e.g. release/v1.2.0, or respectively release/v1.2.0-rc.1 for a release candidate). On the release branch the following steps are executed:

1. Aggregate migrations

Migrations should be aggregated in the case of releasing a new version, in order to not release the entire history of migrations which accumulate during the development process.

Once a version has been released, migrations mustn't be aggregated in order to ensure upgradeability this also applies to release candidates > rc.1 and hotfixes. Be aware that migrations coming release branches for release candidates or from hotfix branches, will need to be incorporated into main.

2. Version bump

The version needs to be updated in the src directory within the 'Directory.Build.props' file.

Also, bump the chart and app version in the Chart.yaml and the version of the images in the values.yaml.

Consortia relevant: Update the version of the targetRevision tag in the argocd-app-templates, used for consortia-environments.

Example for commit message:

build: bump version for vx.x.x

3. Update README (on chart level)

Use helm-docs (gotemplate driven) for updating the README file.

helm-docs --chart-search-root [charts-dir] --sort-values-order file

Example for commit message:

build: update readme for vx.x.x

Update CHANGELOG.md

The changelog file tracks all notable changes since the last released version. Once a new version is ready to be released, the changelog can get updated via an automatically created pull request using the release-please workflow which can be triggered manually or by pushing a changelog/v*.. branch.

Please see:

Merge release branch

The release branch must be merged into main. Those merges need to happen via PRs.

Example for PR titles:

build(1.2.0): merge release into main

Be aware that the merge into main triggers the workflow with the helm-chart releaser action.

The workflow creates a 'ssi-credential-issuer-x.x.x' tag and release. The release contains the new chart.

This workflow also pushes the version tag that triggers the release workflow which creates the versioned docker image/s.

Consortia relevant: The 'ssi-credential-issuer-x.x.x' tag is used to install (with the convenience of the argocd-app-templates) or upgrade the version via AgroCD on the consortia K8s clusters.

RC: provide successive rc branch and change base of open PRs

During a release candidate phase, checkout the successive 'rc' branch and push it to the server, so that it can be used for further bugfixes.

Example:

git checkout tags/v0.1.0-rc.2 -b release/v0.1.0-rc.3

Also make sure to change the base of all open pull requests still pointing to the previous 'rc' branch to the newly pushed 'rc' branch.

NOTICE

This work is licensed under the Apache-2.0.