Gutenberg: Incorrect version in CHANGELOG.md for `@wordpress/data`

[nerrad]

Describe the bug
The @wordpress/data package.json has 4.4.0 (the released version on npm), but the highest version in the CHANGELOG.md file is 4.3.0. Not sure how this should be resolved yet, might need a review of when/where things were published and see where the versions went awry for the changelog.

[youknowriad]

That's not specific to WordPress data, we don't update the CHANGELOG files if there's no "unreleased" entry in the files.

I guess this should be closed once we land #13594

[nerrad]

That's not specific to WordPress data, we don't update the CHANGELOG files if there's no "unreleased" entry in the files.

Can you clarify this a bit more please? Are saying that a package might get a version bump even if there's no changes in that package? Or are you saying there is a case here where someone has forgot to add changes to the CHANGELOG.md and thus it didn't have an Unreleased section, and thus a version didn't get added?

I'm guessing by your reference to #13594 you mean the latter. If so, then should the CHANGELOG.md get updated to have the missing changes for 2.4.0?

If you mean the former, then I wonder if we should add a disclaimer/note to the top of all changelogs that regardless of version of the package, there will only be entries where there are actual changes?

[youknowriad]

I mean the latter but I don't want us to be monitoring changes and updating CHANGELOGs after the fact. I think having a note above changelogs is a solution but a better one is to add checks to avoid missing adding entries in the future.

Are saying that a package might get a version bump even if there's no changes in that package

But, this is also true as Lerna updates all the packages that depend on updated packages even with no changes in the said packages, which makes the note needed regardless.

Edit I guess I mean both :)

[nerrad]

So can I make a suggestion for a note to add at the top of every changelog and then eventually we can do pulls to add it to our packages?

Suggestion (we can iterate):

Note: This change-log is a record of code changes made to the package for each version. Releases involving package dependency updates only are not reflected in this log.

[gziolo]

I think #15740 resolves the issue since we are now using ## Master header to mitigate the fact that we can't always predict the next version of the package published.