How should we handle versioning?

[JohannesKonings]

SemVer? Increase after every merged pull request?
With tags?

[Goala]

Tags should be enough.
Not sure when to increase
It depends on the merge request.
Minor fixes for sure with increasing the patch version.
Every new standard collectors could increase the minor version.

Not sure where to start the current version.
We already have a few collectors implemented. So do we count them into the minor version and with something like 1.5.0.
Or do we just start with 1.0.0 and increase from there the version.

[JohannesKonings]

to start with the number of collectors sounds good for me -> 1.5.0
Should we increase the version number after every pull request or only if the ABAP coding ist affected?

[Goala]

Starting with 1.50 is ok for me.
I would say every change that affects the code base.

@ThoralfHaensel @maierwal any thoughts?

[ThoralfHaensel]

Sounds good to me. I think versioning depends on our release strategy. Every somewhere on a SAP system installed version should have a dedicated version number. Since currently the software is installed via pulling the main branch into the SAP system, every pull request that changes the ABAP coding should result in a new version number.

Should we have a (md) file for the version history? Its easier to read one file than to check the whole commit history.

Should it somehow be possible to see the currently installed version at the SAP system?

[JohannesKonings]

Maybe we can use https://github.com/semantic-release/semantic-release to create tags and a changelog file automatically.

We can show the version number on the selection screen of this program https://github.com/abap-observability-tools/abap-metrics-provider/blob/main/src/zamp_provider/zamp_metrics_provider.prog.abap or in the view cluster.
The version number could be hold in a constant interface and also automatically adapted with every release.

[JohannesKonings]

We can use https://github.com/release-drafter/release-drafter to create releases via labels in pull requests and https://github.com/marketplace/actions/keep-a-changelog-new-release to snyc the CHANGELOG.md

[JohannesKonings]

https://github.com/marketplace/actions/keep-a-changelog-new-release is not fitting because it needs gitFlow.
https://github.com/github-tools/github-release-notes could be an alternative.

[JohannesKonings]

Could be also an option: https://www.nextrelease.io/