Adding a changelog

[observingClouds]

Hi 👋,

Would you be open to having a changelog, e.g. following the Keep a Changelog specs?

Cheers,
Hauke

[leifdenby]

If we add a changelog we should probably tag a first version, no? Otherwise it is hard to reason about what we are making changes relative to.

[observingClouds]

Yes, that sounds good

[leifdenby]

@mpvginde I would suggest you tag v0.1.0 already in that case and we add a changelog, since people are already using mxalign and making PRs to it. And then we can plan that for example v0.2.0 would be the release that introduces delegation of data-loading and spec validation to mlwp-data-loaders and mlwp-data-specs respectively.

If you want I'd be happy to take on creating the changelog and tagging+releasing v0.1.0 (I will add a pypi.org integration for that). We should probably also update the README to more completely reflect the current functionality of mxalign and indicate that some of the functionality is being refactored out. I also think we should merge in #4 before creating v0.1.0.

What do you think?

[mpvginde]

Hi @leifdenby and @observingClouds, I have merged #4, but now I see a lot of failing linting tests.
Could you have a look at them. I'm not so familiar with all this stuff.
Same for the creation of v0.1.0, feel free to tag and release it @leifdenby ;-).

[observingClouds]

Thanks for merging. On a quick glance I see that the linting issues are just from the previous commits that came in before I created the branch for #4. I will open a PR to fix those linting issues. Now that the linters are active, future PRs will be tested to conform to them.

[mpvginde]

Changelog added with #16