Generate changelog with each release

[volkertb]

Fixes #73

[volkertb]

Here is the most recent successful release based on this change in my branch, to give you an idea what the release notes will look like.

@crazii Before you merge this, there are two things you have to be aware of, once this is merged:

• If you want the various commits to be properly "categorized" in the changelog, it's advisable to prefix each commit message according to the "Conventional Commits" format, for example feat: for a new feature, fix: for a bugfix, etc. Any commits that don't follow this conventions will be listed under Other Changes in the changelog.
• With this change, there will be no automatic releases on each push or merge to main anymore. Instead, a release will be triggered when you create a tag and push it, and the tag must be a proper SemVer-compliant version, prefixed with a v.

For instance, to make the first release in this new format:

git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

Before tagging and pushing a new release, you can enter git tag to get a list of existing tags, so you'll know which next version number to use. Whether you only update the patch number (the third number), the minor number (the second number) of the major number (the first number, the left-most one before the first dot) is best up to you to decide, and pretty much depends on the scope and nature of the changes in the release that you are pushing. If it's just minor bugfixes, for instance, you can just increase the patch number.

Oh, and the release notes (changelog going back to the previous release, plus the user instructions that we were always showing in the release up until now) is now being included in both the ZIP file and in the USB image. (In DOS, you can just do type RELEASE_NOTES.md, since Markdown files are perfectly readable as raw text files. 🙂

I know this can all still be improved further, but let's do so incrementally in separate PRs.

Please let me know if you have any questions! If you agree to these conventions and this workflow, feel free to merge this. Thanks! 🙂

[crazii]

I think I can give the conventional commits a try, but I have a few question,

What about PR from others? It's might be hard to force a restriction on everyone.
There's also some WIP commits, are they categorized into other changes? but they're not actually, so I need squash those commits before push to origin?
There also might be failure on bugfixes, so will there be multiple entries in the changelog like: fix: something and another same one or similar one fix: something again?

[volkertb]

Hi @crazii, sorry for the late reply!

To answer your questions:

• No need to enforce restrictions from others. If they don't follow the Conventional Commits convention, their commits will just end up under "Other Changes". Not ideal, but the commits will still be listed in each release.
• Whether or not to squash your commits is best to be judged by you. But indeed, if multiple "work in progress" commits end up making a single feature or fix, you might want to squash them if you prefer to have one commit listed for those incremental changes combined. But I don't think it's that big a deal if you don't want to squash them.
• As for requiring multiple attempts to fix something: well, I'm sure most users understand that that happens sometimes. You can clarify that in the later fix, like fix: soundcard x compatibility, for real now :). Nothing wrong with a little humor, right? 😉

Shall I just merge this and then we evaluate it going forward? I intend to improve and fine-tune it further as needed, and we can always revert it if need be. Just be aware of the git tagging that you need to perform whenever you are ready to perform another release. No longer will a release automatically be generated for each push or merge to main.

Let me know if you're okay with merging and trying this out for awhile.

Thanks! 🙂

[crazii]

the beta4 is planned to be released in a couple of days maybe, I think this PR better merged after beta4 release, leaving beta4 with a manually created changelog, and the auto changelog feature will be merged & tested before next release after beta4.
what's your opinion on it? is it better to merge it right now and test it?

[crazii]

It seems you're busy, no worries,
I added a manual changelog for beta4, and after beta4 this PR will be merged. :D

[volkertb]

Hi @crazii. Sorry for the late reply. If you believe that this PR is better merged after the beta4 release, then let's do that. Thanks! 🙂

[crazii]

OK, I'll get beta4 done and merge it soon.

[volkertb]

Hi @crazii.

Now that you have released beta4, is anything blocking us from merging this?

Asking, since you hadn't pressed the merge button yet. I can also do it, but I want to make sure you're okay with it being merged at this point.

Thanks.

[volkertb]

Oh, maybe you can also approve the PR? Thanks.

[crazii]

I forgot merging it after resolving conflicts.

[volkertb]

Thank you @crazii ! Let's see how well it works with the next few releases, and then evaluate. I'm happy to improve and tweak this in another PR if and when needed. 👍

[volkertb]

@crazii As a reminder: from now on, you need to explicitly git tag a release and push the tag, before a release is built. A new release will no longer automatically be built and published on each push to main.

The upside of this is that you are in control of when a new release is ready.

See the post I shared earlier in this MR thread.