Skip to content

Release Process

Jump to bottom
Erik Jaegervall (Jägervall) edited this page Nov 26, 2024 · 16 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
  • Create github tag
  • Docker containers have been triggered and generated and tested for this repo
  • Create github pre-release of kuksa-databroker
  • 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

markdown-link-checkmay give some false positives, they can be suppressed by accepting certain error codes (in addition to 200). A possible example is below:

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

To check all but ignore some error codes do from root repo folder:

find . -name \*.md -print0 | xargs -0 -n1 markdown-link-check -q -a 403,200,404

As of today CI ignores 200 and 404, and due to limitations in markdown-link-check it also ignores some links where false positive 403 errors are otherwisegiven. It is anyway trecommended to run manually before release including 403 and analyze what needs to be changed.

Update Rust versions

Find every Cargo.toml, replace version. Do not (by default) update edition, it concerns Rust edition, not package release date.

Can be done by running scripts/prepare_release.sh <version>

Do a cargo update, make sure that version is as expected

erik@debian3:~/kuksa-databroker$ !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

Also update lib/Cargo.lock

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 quit

cargo run --bin databroker-cli


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

Proposed Versioning Scheme

Use X.Y.Z only for the commit that matches the release. For other use-cases use a pre-release identifier.

  • For development branches set version to X.Y.Z-pre.0, for example 0.4.7-dev.0 where the number is a possible number for the next release on that branch. In general it does not matter that much if you after release of 0.4.6 sets it to 0.4.7-dev.0 or 0.5.0-dev.0, the important part is to highlight that this is a development version. You should never create a tag or release with a "dev" version
  • If you need to tag and/or release something for testing purposes, use alpha or rc as prerelease-tag

References:

Automated Release Workflow

Create and upload tag

image

Then trigger build

(we could later possibly let it be automatically triggered by the tag push)

Right now starting from main will not create a valid release due to tag name selected

image

Action after automated release flow

  • Manually select previous release and generate release notes
    • Change tag to only X.Y.Z if needed
  • 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 files
  • Select "Set as a pre-release "

Docker containers (Not if using Automated Flow)

Trigger databroker and databroker-cli builds manually (only needed if NOT triggering automated flow above)

Create Databroker Github release (Not if using Automated Flow)

Create a release & maintenance branches (If not already done)

  • Create release/X.Y.Z, e.g. release/0.5.0. This is if anyone prefers a branch, possibly together with a tag, to reference this particular release. Seems like Yocto/AGL benefits from this
  • Create a patch branch of the form 0.5.X, this is for patches, if any

Inform Project Lead

It is the official project lead that needs to approve that the release is marked as an official release and as latest release

Update main to point to new version

Update to something like 0.6.0-dev.0 Can be done by running scripts/prepare_release.sh <version>

Checklist Template

  • Make sure we are feature complete
  • Check links
  • Update RUST versions
  • Perform testing
  • Create local release tag
  • Create github tag
  • Docker containers have been triggered and generated and tested for this repo
  • Create github pre-release of kuksa-databroker
  • 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