documentation of changes triggering version updates

[pabigot]

Thanks for keeping this package moving forward.

Would you consider keeping a changelog in the repository source?

I notice that this package is now version 1.2.0, compared to 1.1.0 that I've been using. I can find no clear description of the differences, but running a diff shows it contains #20, #23, and #25, and by looking at those I can infer at least #23 justifies the minor update.

If a CHANGELOG.md is maintained in the main branch and updated with each merge, that would make it easier to review at release time to ensure version tags are updated where appropriate. E.g. #26 has been merged which warrants a version update but that doesn't seem to be recorded anywhere.

[lukebakken]

Hello,

Thanks for using this library and for the suggestion. Would you be willing to submit a PR to add CHANGELOG.md in the root of this repository?

I will go back through pull requests to try to assign them to the appropriate milestones. Personally I think that's the best way to track changes.

As for #26 it's debatable whether that should be in version 1.3 or 1.2.1 as the PR fixes a long-standing bug. @michaelklishin ???

[Zerpet]

I believe we decied to ship #26 as a minor, based on this comment #26 (review)

[pabigot]

@lukebakken While I'd like to help, I'm not a maintainer here, and exactly what goes into a changelog, and making a commitment to keeping it accurate, is something the maintainers would have work out. I don't think I could adequately reconstruct what has been done and why to populate an initial changelog. If somebody else wants to, https://github.com/pabigot/buffer-layout/blob/main/CHANGELOG.md shows an example.

In any case, the underlying issue is that there's no way to understand what actually changed in a release, so as to update client code or anticipate possible behavior changes. If that can be accomplished with milestones, especially if they're associated with a tagged release and trace back directly to closed issues and PRs without having to trace individual commits, that could be enough.

[lukebakken]

At this point we'll strive to use milestones and release notes effectively. I've gone through all the closed pull requests that changed code and have added them to milestones for the version in which the PR was released.