Update changelog, add automated release workflow

[renestalder]

This PR contains:

• Manually update the current changelog to contain the latest changes, written in a conventional release fashion.
• Add GitHub action to automatically tag, create version file, update changelog and create GitHub releases via release-please.
• Add contribution guidelines.

Manually update the current changelog to contain the latest changes, written in a conventional release fashion.

The changelog that was not updated for the last 5 years now contains the latest changes, in a conventional release fashion. As many commits do not follow proper conventional commit guidelines, the manually updated changelog contains some additional information found in the PRs of those changes.

No versioning information apart from dates was added, as there were no proper tags created since the end of 2023.

Add GitHub action to automatically tag, create version file, update changelog and create GitHub releases via release-please

If people follow proper conventional commit rules, the changelogs will now automatically be created based on those commits, and tags and GitHub releases automatically created, allowing for better release workflows without additional work.

For this to work, code reviewers have to make sure, the commits that are supposed to be merged into master follow the conventional commit guidelines.

Also, more granular commits create better changelogs. Example:
#74

• Contains multiple changes in one commit.
• Commit message subject is not useful.

How to do it otherwise:

• Separate refactoring, performance and feature/fixes in separate commits. In this case, this would have been at least one perf, one refactor and either a feat or fix commit.
• Add proper commit subjects that are useful when found in the changelog.

Add contribution guidelines

As for the conventional commits guidelines.

[renestalder]

@xarem @sbaerlocher @s4mpl3d @robinlehrmann Let's give this a proper lift in useful documentation: I went a step further than only updating the changelog a bit, but also added tooling. Because we can either try to get people to keep that up to date, tag and create releases, or automate it like many others do.

I added an automatic versioning, tagging, change logging and releasing task. Nothing spectacular. Something that is found in many small and big projects and is very common. I use a different tool in my personal projects that also works with GitLab, but release-please seemed more appropriate for our approach with GitHub projects, and also has a bit more active maintenance.

For it to work properly, it needs a personal access token. And for that, we should add it from a generic whatwedo account. Advice required:

• I don't have permissions to edit the project
• I don't have permission to an account like that.

[s4mpl3d]

@renestalder Amazing, thanks! I neither have access to the token currently. Will organize one next week 👍

[renestalder]

Meanwhile, I got access to the project settings and I see that in our internal 1password, there is now a bot account. But I didn't hear anything back on my question for advice and how to proceed.

So my assumption is, that I can proceed with these permissions to finish the setup. Is that correct, @s4mpl3d?

[renestalder]

@xarem @sbaerlocher @s4mpl3d @robinlehrmann Gonna close this one by the end of the week without any response from any of the current code owners on my question what your expectations are for me on how to proceed.

[s4mpl3d]

@renestalder Didn't we discuss this already 🤔? You can proceed with these permissions to finish the setup. Or is there another question pending?

[renestalder]

@s4mpl3d Thanks. Will do so.

Didn't we discuss this already 🤔?

Nobody told me anything about how to proceed, up to today, so no, we didn't. At least not in my presence or by letting me know.

[sbaerlocher]

@renestalder The action has been moved and is now available at https://github.com/googleapis/release-please-action.

@s4mpl3d According to the documentation, we only need a Personal Access Token (PAT) if we want the action to trigger further GitHub Actions, e.g. when creating pull requests. If we don't need this functionality, we can use the GITHUB_TOKEN provided by default in GitHub Actions.