[docs] Publish changelog to gh-pages

[chme]

It would be nice to include the changelog in the OwnTone documentation.
To not have to manage two places for the changelog, the snippets Markdown extension is used.

The ChangeLog file remains the place to keep and edit the changelog/releases. In order to have a nicely rendered page in the mkdocs documentation, it was reformatted to Markdown (I checked the GNU docs and I could not find any formatting requirements - so I think, this should be fine).

• Format ChangeLog in Markdown.
• Publish ChangeLog as part of the mkdocs documentation to gh-pages.

Some other unrelated changes to the docs:

• Fix formatting of sub lists on docs index page.
• Add automatic light/dark mode for docs (mkdocs-material docs).
• Make dark mode a bit darker by switching the primary color from "blue gray" to "black".

You can see the generated docs with these changes at https://chme.github.io/forked-daapd.
Direct link to the integrated changelog: https://chme.github.io/forked-daapd/changelog/

[chme]

FYI: There are also nice tools that help generating / updating a changelog from the git commit history. For example, I really like https://pawamoy.github.io/git-changelog/. But it would require to change the commit message convention, most of these tools expect https://www.conventionalcommits.org/en/v1.0.0/ (or similar).

(It might also be possible to implement some extension to make them understand the current convention used in owntone.)

[ejurgensen]

Looks great, you are welcome to merge.

There are also nice tools that help generating / updating a changelog from the git commit history

My experience with auto-generated changelogs is that they struggle with extracting what's relevant for the end user. That's actually also difficult for me when I scan through the commits - I'm not always sure what the actual improvement is, just from reading the commit message. Another difficulty is that sometimes a commit fixes a regression from a commit that was after the latest release, and they should of course be ignored, but it's not always evident from the commit message.

[chme]

My experience with auto-generated changelogs is that they struggle with extracting what's relevant for the end user. That's actually also difficult for me when I scan through the commits - I'm not always sure what the actual improvement is, just from reading the commit message. Another difficulty is that sometimes a commit fixes a regression from a commit that was after the latest release, and they should of course be ignored, but it's not always evident from the commit message.

Yes, the auto-generated changelogs do still require manual editing to make them readable for users. The stricter rules for commit messages, commit size and pull requests are enforced, the better their output can become.

But in my experience they at least help to reduce the tedious work to go through the changes by gathering the information and already formatting them. But of course the issues you mention still persist.

(I would not auto-generate the changelog in a CI action, but it could be e. g. a make goal, that would be run locally when preparing a release (maybe also with bumping the version). Its just an idea, you are the best judge if it would help for an owntone release or not.)