feat: +bump-my-version, moved deps to dev-deps, removed unneeded deps

[sschleemilch]

About

Main idea is to add extending the CHANGELOG.md on pull-requests with sections defined accoring to keepachangelog.

When doing a release, a maintainer can exchange the Unreleased section with a release version, bump the version, create a tag and uploading it with twine

• Added bump-my-version config file and dev dependency
• Added keepachangelog reference to CHANGELOG.md
• Added Release section in README.md with instructions for maintainers
• Added twine to dev dependencies

[erikbosch]

In the past we have used something like 6.0a0 on main to avoid that a local build will be presented as 6.0.0 on the CLI and build logs, i.e. preferably only the official 6.0.0 build shall present it self as 6.0.0 in build logs. The reason is that in the past we sometimes had problems that people had problem with vss, and it turned out they were using a developer-version or a version that was dirty in some other way.

[sschleemilch]

bump-my-version has also support for rc and or dev releases: https://github.com/callowayproject/bump-my-version?tab=readme-ov-file#add-support-for-pre-release-versions

[sschleemilch]

Added the dev suffixes and extended the README.

Workflow would then be:

• main has -dev0 suffix for the version
• bump-my-version [minor|major|patch] on release and tag it
• bump-my-version pre_n afterwards on main to develop for the next one

[erikbosch]

Will this bump .bumpversion.toml, pyroject.toml or both?

[sschleemilch]

both

[erikbosch]

I am in general positive to the change but if/when merged we would need to look a bit on https://github.com/COVESA/vehicle_signal_specification/wiki/Release-Instructions-and-Checklist (which covers both vss and vss-tools as of today) and check what updates that are needed. The part that might need some update is how to update version identifier. As of today we typically do it at:

• When preparing a release candidate we give a version like 6.0.0.rc0
• Then at the release we set a released version, like 6.0.0
• The after release we change to something else so that it is clear that you are using a local/unreleased version if you build from latest master-version or download a built artifact from github actions, like 6.1.0dev0

I assume that setup works also after this, but then maybe instructions needs to be somewhat modified, for instance by referring to the README.

[erikbosch]

For dev release the number should be next release? Or alternatively a post release? https://peps.python.org/pep-0440/#developmental-releases

[erikbosch]

MOM:

• Please review

[erikbosch]

@sschleemilch - for your info, at the meeting yesterday we agreed to release vss 5.1 but not vss-tools 5.1. But @SebastianSchildt came with the good suggestion to release vss-tools 6.0 "soon" (but after vss 5.1 has been released). The rationale is that we have quite some changes on vss-tools that would be good to get out. That would also be a start on letting vss and vss-tools have separated release cycles. I.e. Vss 5.x will still specify in https://github.com/COVESA/vehicle_signal_specification/blob/master/scripts/install_vss_tools.sh that it wants a vss-tools 5.x version, but vss on master will (as today) use the latest version from master.

With that said, if you like to you could be responsible for creating vss-tools 6.0 when it is time for it to test out the changes in this PR and update the wikis as needed. We may however wait for @jdacoello as he has some GraphQL changes in progress that possibly better should be included in the vss-tools 6.0

[sschleemilch]

@sschleemilch - for your info, at the meeting yesterday we agreed to release vss 5.1 but not vss-tools 5.1. But @SebastianSchildt came with the good suggestion to release vss-tools 6.0 "soon" (but after vss 5.1 has been released). The rationale is that we have quite some changes on vss-tools that would be good to get out. That would also be a start on letting vss and vss-tools have separated release cycles. I.e. Vss 5.x will still specify in https://github.com/COVESA/vehicle_signal_specification/blob/master/scripts/install_vss_tools.sh that it wants a vss-tools 5.x version, but vss on master will (as today) use the latest version from master.

With that said, if you like to you could be responsible for creating vss-tools 6.0 when it is time for it to test out the changes in this PR and update the wikis as needed. We may however wait for @jdacoello as he has some GraphQL changes in progress that possibly better should be included in the vss-tools 6.0

Not sure what all of that has to do with this PR though.

So the idea of the 5.0.0-dev0 is that it reads as "Developing something after 5.0.0"

Then you can decide when releasing what the next should be.
bump-my-version shows available bump paths from -dev0:

❯ bump-my-version show-bump
5.0.0-dev0 ── bump ─┬─ major ─ 6.0.0
                    ├─ minor ─ 5.1.0
                    ├─ patch ─ 5.0.1
                    ├─ pre_l ─ invalid: The part has already the maximum value among ['dev'] and cannot be bumped.
                    ╰─ pre_n ─ 5.0.0-dev1

[erikbosch]

Most of my last commit has not not much to do with this PR.
But looking at the bump my version example which seems quite similar to what we have done in the past for vss-.tools I would say 5.0.0-dev0 is intended to indicate something that may become 5.0.0 in the end.

There example uses an rc identifier as well, which we also have used.

[sschleemilch]

I would say 5.0.0-dev0 is intended to indicate something that may become 5.0.0 in the end.

I don't think so. It can evolve into 6.0.0 or 5.1.0. if we want to have additional milestones in the dev cycle it could also turn into 5.0.0-devN

[erikbosch]

I would say 5.0.0-dev0 is intended to indicate something that may become 5.0.0 in the end.

I don't think so. It can evolve into 6.0.0 or 5.1.0. if we want to have additional milestones in the dev cycle it could also turn into 5.0.0-devN

I guess it depends on how you define your paths, if we look at the example in https://github.com/callowayproject/bump-my-version?tab=readme-ov-file#visualize-the-new-versioning-path

... they show that you from 0.1.0 can go to various dev versions. From a dev version you can go to an rc version and from rc to a released version. They also show a path 1.0.0 -> 1.0.1-dev0 -> ... -> 1.01. So if we would use their config example which is quite similar to what we have done so far there would be a path from 5.0.0-dev0 (via 5.0.0-rc0) to 5.0.0.

[sschleemilch]

Okay, seems like I did not understand how it works. So extending values does the trick.
Anyway, not sure how we want it to be now :D

[erikbosch]

I would suggest extending with rc at we then would fit quite well how we work today. Like this

[erikbosch]

LGTM