The elastic-package changelog add command should incorporate unreleased changelog notes into the new version that it adds. For example, if the changelog contains the content below and the manifest version is on 1.15.0, then all of the newer changes are unreleased and should be rolled into the added version. So then this

- version: "1.16.0-next2"
  changes:
    - description: "Some unreleased change"
    ...
- version: "1.16.0-next"
  changes:
    - description: "Other unreleased change"
    ...

becomes

- version: "1.16.0"
  changes:
    - description: "Update to ECS 1.2.3".
    ...
    - description: "Some unreleased change"
    ...
    - description: "Other unreleased change"
    ...

Today's implementation is treating the latest entry in the changelog¹ as the latest released version. I think it should be using the manifest version as the starting semver for bumping major/minor/patch.

Use-case

When automating changes it is very easy to overlook that unreleased changes were added to the changelog via a x.y.z-next entry. The tool can detect these by comparing if their versions are newer than manifest version, and then when they are merged into the requested changelog entry it should be more clear to the developer that they are releasing additional changes beyond their own.