Create and tag release versions + Change log

[monamok]

Hello! I think we need to start adapting this subproject in terms of versioning according to this recommendation:

https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/SupportingDocuments/Camara_Versioning_Guidelines.md

At least the MWC intial version should be tagged and have the release branch.

@bigludo7 @DT-DawidWroblewski I'm not the code owner so I don't have permissions to do it. Could you please do it?

We also have to decide about the latest version in main branch. Should we call it version: x.y.z-WIP?

[monamok]

Dear @bigludo7 @DT-DawidWroblewski, I checked again and as a mantainer I don't have permissions to create a release. Te instructions are here: https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

The v0.1.0 can be created from commit "db1665" and changelog.md need to be added. I already prepared the changelog file but I just can create branches in my forked repository and then as the release branch does not exist here I can't open a Pull request.

Could you please handle it or at least create the branch so I can open a new PR against that branch?

[monamok]

According to the guidelines, the release branches must be called release-x.y.z
For example for the first one, it should be release-0.1.0
For more info please check the link in the issue description.

[hdamker]

@DT-DawidWroblewski:

Here are some best practice steps to create a release according to the Camara_Versioning_Guidelines (tested e.g. within QualityOnDemand):

• Close/merge all issues/PRs the sub project has agreed to do before the release
  • It could be helpful to have an issue "Release vX.Y.Z" which is listing the Issues/PR which have mandatory to be done before the release
• Create a "release" pull request with the update of the CHANGELOG.md within root of the project
  • use CHANGELOG_TEMPLATE.md for the content
  • The PR can include - if needed - the final update of the version number for the release in the OAS file (e.g. change from v0.x.0-wip to v0.x.0 or v0.x.1)
  • It could be helpful to use the release feature of Github to collect the content for the changelog ... just "Draft a release" but don't publish it already. Copy the content over into the CHANGELOG.md, sort according to the PR (and some items are not needed within the CHANGELOG) (that can to be done only by a codeowner with write access)
• The "release" PR will be discussed and approved as usual. The merge commit will get the "release commit"
• Use the release feature of Github to create the release tag on this "release commit", copy the content of the CHANGELOG.md as the release description
  • That need to be done by one of the code owners (with write access)
• Create the "release branch" (e.g. release-v0.x.y) in the repository
  • Note: the release branch should be protected by a rule. If this is not the case please ask a CAMARA admin to create the rule in the repository
• Update the README of the sub project accordingly (see QualityOnDemand as an example)
• Consider to change the release number within the main branch to e.g. v0.[x+1].0-wip to avoid confusions with the released version