In #2002 it became obvious that the changelog process is not optimal. we should handle the changelog better. The following requirements are present:

• The changelog in the master branch represents the complete history of all versions also on the main-* branches.
• The file CHANGELOG.md should not be changed on each PR to prevent conflicts during rebasing and backports
• During the release process, the CHANGELOG must be updated automatically without manual intervention

Steps to carry this out:

T.B.D.

Sketch of a solution:

One idea is to put the changelog entries for each PR into a dedicated folder .changelog. Each PR has its own file. The filename is always beginning with the PR name and a dash (e.g. 1234-) to guarantee uniqueness. Such a PR changelog is build similar to a changelog file. For example, for PR #2015, the file .changelog/2015-add-missing-translation could look like

### Fixed
- Add missing translatable string for recipe-creation button in empty list view

Optionally, before the ### Fixed, there could be a line Authors: @seyfeb (or multiple) to declare the authors responsible for the PR.

The CHANGELOG file itself is not modified during normal development. The PR changelogs are kept within the individual branches (master, main-*). There is one more (isolated) branch changelogs to be created. This branch must have linear history and will not be used by normal devs. It contains no files except for a basic README (to explain its usage) and version changelogs (just read on).

During the release process, the changelog needs to be fixed. So, any yet unreleased entries must be collected and combined into a bundle. This can be done in a script (part of the release scripts should be possible). The unreleased PRs are in fact the pr-changelogs in .changelog of the corresponding master or main-* branch. So, the script will iterate these files and create an output that represents a version-changelog. It needs to collect all change types (Fixed, Changed, Added, ...) and combine the texts, augment by a link to the PR (number is known from the file name) and author information (either from Authors field in file or from author mail in git commit). The result is similar to e.g.

## 0.10.4 - 2023-12-05

### Fixed
- Make app compatible with PHP 7.4
  [#1931](https://github.com/nextcloud/cookbook/pull/1931) @christianlupus
- Remove constant se in RecipeView
  [#1942](https://github.com/nextcloud/cookbook/pull/1942) @j0hannesr0th

### Maintenance
- Add PHP lint checker to ensure valid (legacy) PHP syntax
  [#1931](https://github.com/nextcloud/cookbook/pull/1931) @christianlupus
- Add backport script to simplify development
  [#1935](https://github.com/nextcloud/cookbook/pull/1935) @christianlupus

This is a version changelog (in this case from 0.10.4). The script during the release process will use this output and commit a file changelogs/v0.10.4 to the changelog branch. The filename is derived from the tag name of the version to create. So, it could also be changelogs/v0.11.0-rc1.

Depending if this is a prerelease or not, the folder .changelog in the actual master or main-* folder must be cleaned up. Additionally, the file CHANGELOG.md must be reconstructed from all snippets in the changelog branch. Additionally, the CHANGELOG.md on the master branch must be updated as well if working on a main-* branch.

Before starting to implement this, do you think this might work, @seyfeb?