Clarification of CHANGELOG requirements for first release candidate with previous alpha release

[hdamker]

Problem description

Within the CHANGELOG template it is stated:

• for each first alpha or release-candidate API version, all changes since the release of the previous public API version
• for subsequent alpha or release-candidate API versions, the delta with respect to the previous pre-release
• for a public API version, the consolidated changes since the release of the previous public API version

For the case that a first release candidate version (e.g. 0.6.0-rc.1) follows after an alpha API Version (e.g. 0.6.0-alpha.1) which followed a public version (e.g. 0.5.1) there are two interpretations possible:

A) 0.6.0-rc.1 is the "first release candidate API version", and all changes since the release of the previous public API Version (0.5.1) has to be recorded in the changelog update entry

B) 0.6.0-rc.1 is a "subsequent alpha or release-candidate API version" and only the delta with respect to the previous pre-release (0.6.0-alpha.1) has to be recorded in the changelog update entry.

Expected action

The text within the CHANGELOG should be unambiguous.

My personal interpretation would be A) for two reasons:

• audience interested in release candidates is another one than for alpha releases (they are mostly only snapshots of the repository)
• there is the option that changes of the alpha version has been (partly) reverted, that would be difficult to identify, especially if multiple alpha versions preceded.

The text could be for option A):

* for an alpha release, the delta with respect to the previous release
* for the first release candidate, all changes since the last public release
* for subsequent release candidate(s), only the delta to the previous release candidate
* for a public release, the consolidated changes since the previous public release

Additional context

[hdamker]

Adding backlog label, to be considered for next meta-release cycle (avoid change for current one).