Skip to content

Draft: Split CHANGELOG into two files (#406)

Explanation of changes

Split up CHANGELOG.md into two files:

  • CHANGELOG.md (name unchanged wrt. previous file to avoid changes for developers): keeps track of unreleased changes. To be modified in each MR. The merge checklist does not need to be changed. Also the merge strategy remains unchanged, because we still want to avoid conflicts in this file when multiple users change the same line.
  • CHANGELOG_released.md: keeps track of released changes. To be modified by maintainers when preparing for a release.

I tried to verify that this works, but was not successful (see message below). I'm not sure if there is a reasonable, straightforward solution.

Motivation of changes

Follow-up to !495 (merged). This MR did its job quite nicely. But it had the side effect that after releases, in which the file is heavily edited, many entries are duplicated in on-going MRs.

Described in more detail in #406 (closed).


Merge checklist

See also merge request guidelines

  • Merge request has been reviewed (in-depth by a knowledgeable contributor), and is approved by a project maintainer.
  • New code is covered by unit tests (or N/A).
  • New code is documented and docstrings use numpydoc format (or N/A).
  • New functionality: considered making private instead of extending public API (or N/A).
  • Public API changed: added @deprecated (or N/A).
  • Tested on hardware (or N/A).
  • CHANGELOG.md and AUTHORS.md have been updated (or N/A).
  • Windows tests in CI pipeline pass (manually triggered by maintainers before merging).

For reference, the issues workflow is described in the contribution guidelines.

Edited by Konstantin Lehmann

Merge request reports

Loading