Release Process

Note! Page copied from kuksa.val.feeders and may need refactoring

This page describes the release process for KUKSA Can Provider. The term release here refers to

• Testing content and when passed tag the repository
• Release docker containers

Release Preparations

• Make sure that wanted versions of KUKSA.val components have been released (Databroker, kuksa-client pypi package and so on). See KUKSA.val release process

A suggested approach when it is time to release CAN Provider component is to:

• Make sure that a stable new kuksa-clientexists in pypi.
• Adapt all requirements.in, requirements.txt (search for requirements* files) so they use the official version, for example kuksa-client ~= 0.4.0 to assure that only 0.4 version can be used. Alternatively 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
• Remove all --pre statements from e.g. Dockerfileand *.yml (search for --pre in all files) to make sure that not we by mistake get pre-releases.

Preferred kuksa-client dependency criteria is:

• >=X.YaN during development if we cannot use last released version, remeber to add --pre where needed
• ~=X.Y for releases and master/main, to make sure we use a compatible version. Upgrading shall always be a deliberate action

This means - for a release we first change to a fix version, test, tag and release. Then we may change to a >=dependency.

File	What to do
*.txt, *.in	Search for kuksa-client and update version
*.in	Regenerate *.txt with pip-compile --pre requirements.in or pip-compile requirements.in
Dockerfile	Search for pip install and pip3 install and add/remove --pre as needed for installation of requirements.txt

find . -name "*.txt" -exec egrep -ni kuksa {} /dev/null \;
find . -name "*.in" -exec egrep -ni kuksa {} /dev/null \;
find . -name "Dockerfile" -exec egrep -ni pip {} /dev/null \;

Test

See KUKSA Feeders Release testing

Tag repo

erik@debian3:~/kuksa.val.feeders$ git checkout erik_main
Switched to branch 'erik_main'
Your branch is behind 'upstream/main' by 4 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
erik@debian3:~/kuksa.val.feeders$ git rebase upstream/main
Successfully rebased and updated refs/heads/erik_main.
erik@debian3:~/kuksa.val.feeders$ git tag 0.4.0
erik@debian3:~/kuksa.val.feeders$ git push upstream 0.4.0
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/eclipse/kuksa.val.feeders
 * [new tag]         0.4.0 -> 0.4.0

Create Docker releases

Trigger manually for all packages we have by selecting the corresponding action and trigger for the used tag.

Create Github release

For now we keep it simple and try to reuse kuksa.val format

• Use the form kuksa-can-provider 0.4.0 Release
• Tick the "Set as a pre-release" box
• Select Previous release tag and generate release note
• Add a "What is new" section, make a summary based on git history