Release Process

Note! dbc2val currently being migrated to new repo, instructions here partially outdated!

This page describes the release process for artifacts in this repository. The term release here refers to

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

All docker artifacts are listed at: https://github.com/orgs/eclipse/packages?repo_name=kuksa.val.feeders

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 a kuksa.val.feeder 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. 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
• 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 at https://github.com/orgs/eclipse/packages?repo_name=kuksa.val.feeders by selecting the corresponding action in https://github.com/eclipse/kuksa.val.feeders/actions and trigger for the used tag.

currently:

Note: For SOMEIP no reason to build binaries, does not affect docker build!

Create Github release

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

• Use the form KUKSA.val.feeders 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

Docker Version Matrix

Component	main	tagged	latest	other
dbc2val	yes	yes	no	no
gps	yes	no	no	pr-34
someip-feeder	no	no	yes (on latest main)	edge, sha...
csv-provider	yes	no	no