Skip to content

Release Process

Jump to bottom
Erik Jaegervall edited this page Nov 22, 2023 · 33 revisions

This page describes how to release components in this repository. For testing purposes we need components in other repositories, and if it is planned to release multiple components it could be an idea to perform the release processes and release testing in parallel.

For reference:

See also content of previous releases

Checklist

  • Make sure we are feature complete
  • Check links
  • Update RUST versions
  • Perform testing
  • Create local release tag
  • Update Python requirement files
  • Update if needed kuksa-python-sdk and kuksa.val.feeders
  • Feeder test passed (Not Alpha components/features)
  • Create github tag
  • Docker containers have been triggered and generated and tested for both this repo
  • Create github pre-release of kuksa.val
  • Merge release-branches (if used) back to master/main
  • Project lead informed
  • Official release approval received
  • Releases transformed to official releases

Release Process in short

  1. Merge all functional changes that should be included

  2. Perform testing according to https://github.com/eclipse/kuksa.val/wiki/Release-Testing

  3. When all findings are corrected and if needed retested, then tag and upload a tag

  4. If it works create a Github pre-release

  5. Ask project owners to review and approve release, When done transform to real release

Checking links

The commands below can be used to verify that links in markdown files works as expected

npm install -g markdown-link-check

find . -name \*.md -print0 | xargs -0 -n1 markdown-link-check

Or stricter:

markdown-link-check -q -a 403,200,404 *.md

To check all but ignore third party (submodule) code do from root repo folder:

find . -name \*.md -not -path "./kuksa-val-server/3rd-party-libs*" -print0 | xargs -0 -n1 markdown-link-check -q -a 403,200,404

Update Rust versions

Find every Cargo.toml, replace version. Do not (by default) update edition, it concerns Rust edition, not package release date. Do a cargo update, make sure that version is as expected

erik@debian3:~/kuksa.val$ !2247
cargo update
    Updating crates.io index
    Updating databroker v0.3.1 (/home/erik/kuksa.val/kuksa_databroker/databroker) -> v0.4.0
    Updating databroker-cli v0.3.1 (/home/erik/kuksa.val/kuksa_databroker/databroker-cli) -> v0.4.0
    Updating databroker-examples v0.3.1 (/home/erik/kuksa.val/kuksa_databroker/databroker-examples) -> v0.4.0
    Updating databroker-proto v0.3.1 (/home/erik/kuksa.val/kuksa_databroker/databroker-proto) -> v0.4.0

Alternatively we could update only databroker, see https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html, but likely good to update everything

Verify that databroker-cli reports right version


  ⠀⠀⠀⢀⣤⣶⣾⣿⢸⣿⣿⣷⣶⣤⡀
  ⠀⠀⣴⣿⡿⠋⣿⣿⠀⠀⠀⠈⠙⢿⣿⣦⠀
  ⠀⣾⣿⠋⠀⠀⣿⣿⠀⠀⣶⣿⠀⠀⠙⣿⣷   
  ⣸⣿⠇⠀⠀⠀⣿⣿⠠⣾⡿⠃⠀⠀⠀⠸⣿⣇⠀⠀⣶⠀⣠⡶⠂⠀⣶⠀⠀⢰⡆⠀⢰⡆⢀⣴⠖⠀⢠⡶⠶⠶⡦⠀⠀⠀⣰⣶⡀
  ⣿⣿⠀⠀⠀⠀⠿⢿⣷⣦⡀⠀⠀⠀⠀⠀⣿⣿⠀⠀⣿⢾⣏⠀⠀⠀⣿⠀⠀⢸⡇⠀⢸⡷⣿⡁⠀⠀⠘⠷⠶⠶⣦⠀⠀⢠⡟⠘⣷
  ⢹⣿⡆⠀⠀⠀⣿⣶⠈⢻⣿⡆⠀⠀⠀⢰⣿⡏⠀⠀⠿⠀⠙⠷⠄⠀⠙⠷⠶⠟⠁⠀⠸⠇⠈⠻⠦⠀⠐⠷⠶⠶⠟⠀⠠⠿⠁⠀⠹⠧
  ⠀⢿⣿⣄⠀⠀⣿⣿⠀⠀⠿⣿⠀⠀⣠⣿⡿
  ⠀⠀⠻⣿⣷⡄⣿⣿⠀⠀⠀⢀⣠⣾⣿⠟    databroker-cli                
  ⠀⠀⠀⠈⠛⠇⢿⣿⣿⣿⣿⡿⠿⠛⠁     v0.4.0

Update Python requirement files

  • Adapt all requirements.in, requirements.txt (search for requirements* files) so they use the official kuksa-client version, for example kuksa-client ~= 0.4.0 to assure that only 0.4 version can be used. Alternativetely we can keep > 0.3 if we like to allow also even newer kuksa-clients, like 0.5, but then we should anyway regenerate requirements.txt (with pip-compile -U requirements.in instead of pip-compile --pre requirements.in) to include an official version.
  • Review all .in/.txt-files; check if there is a need to do any update in dependencies. In the future check for known vulnerabilities. Regnerating with -U typically makes sense

Docker containers

Trigger builds manually

image

In total 3 builds, below plus kuksa-val:

image

Do the same for feeder

Create KUKSA.val Github release

  • Tag the repo and upload tag
  • Hopefully this will trigger builds of at least databroker and databroker-cli and publish new docker containers
  • Fetch *.zip binaries for databroker and databroker-cli

Take latest arm64/amd64 images from latest build on master (or the right tag)

https://github.com/eclipse/kuksa.val/actions/workflows/kuksa_databroker_build.yml

https://github.com/eclipse/kuksa.val/actions/workflows/kuksa_databroker-cli_build.yml

I.e. in total 4 *.zip files shall be downloaded and added to the release

  • Create a pre-release based on tag.
  • For now, as long as repo has not been split, the release name shall be KUKSA.val X.Y.Z Release
  • Manually select previous release and generate release notes
  • Copy instructions based on previous release (part above ## What's Changed), i.e. information on how to fetch from docker
  • Also say something about the included *.zip files
  • Select "Set as a pre-release "

Update if needed kuksa-python-sdk and kuksa.val.feeders

In theory this repo can be released independently from downstream repos like kuksa-python-sdk and kuksa.val.feeders. But if backward incompatible changes are introduced in KUKSA databroker or KUKSA server it is recommended to do one of:

  • Create an issue in the downstream project/repo that is not compatible with the new version, to make sure that they are aware
  • Implement required changes in the downstream project/repo

Checklist Template

  • Make sure we are feature complete
  • Check links
  • Update RUST versions
  • Perform testing
  • Create local release tag
  • Update Python requirement files
  • Update if needed kuksa-python-sdk and kuksa.val.feeders
  • Feeder test passed (Not Alpha components/features)
  • Create github tag
  • Docker containers have been triggered and generated and tested for both this repo
  • Create github pre-release of kuksa.val
  • Merge release-branches (if used) back to master/main
  • Project lead informed
  • Official release approval received
  • Releases transformed to official releases
Clone this wiki locally