Add a CHANGELOG.md file to track schema changes.

[connorshea]

Resolves #1992. The reason I'd like the project to have a Changelog is so I can more easily update my Explorer webapp whenever a schema change occurs.

This is meant to track:

• Adding/removing attributes from the schema, e.g. if a spec_url attribute was added to track WHATWG/W3C specs for a given feature, or if the mdn_url attribute was removed from the dataset.
• Changes to the types allowed for a given attribute, e.g. if the description was changed from allowing only String to allowing either a String or an Array, in order to support localization.
• Changing names of attributes, e.g. something like renaming mdn_url to mdn_link.
• Adding new data categories, e.g. when the mathml/ directory was added in Begin work on converting MathML data #1740.
• Changing whether an attribute is optional, e.g. making status mandatory.
• Changes to attribute exclusivity, e.g. making prefix and alternative_name mutually exclusive like in Make prefix and alternative_name mutually exclusive #1836.

I don't think it should track every change to the dataset as that'd cause unnecessary friction, and the commit log should be sufficient for tracking that information.

Maybe it should also track adding new browsers? I'm not sure about that one.

[Elchi3]

An alternative would be to add notable changes to the tags directly. I've done that experimentally for 0.0.45 here: https://github.com/mdn/browser-compat-data/releases/tag/v0.0.45 and it appears nicely in the release history: https://github.com/mdn/browser-compat-data/releases

I think I would prefer that and can make that my habit whenever I release a new package version. What do you think?

[connorshea]

As long as you make it a habit, that's fine by me. Ideally it'd be in the git repo properly (I'm not 100% sure, but I don't think GitHub stores Release descriptions as part of the tags in the repo, so they aren't really portable). Also, people may not look at the Releases page, and it's not possible for others to contribute to it.

That said, your workflow matters the most since you're the maintainer, and if it's a choice between releases as the place to find breaking changes, or nothing, releases is obviously better :)

[Elchi3]

OK, I'm trying out github releases for this and will keep this open for now to add more release notes to past tags.

[Elchi3]

Happy so far with the release notes for 0.0.50 to 0.0.58: https://github.com/mdn/browser-compat-data/releases

[connorshea]

Did you mean to include the bit of code after the total features?

[Elchi3]

Did you mean to include the bit of code after the total features?

No, it's probably not the right place. I've added the snippet to the publishing instructions instead in #3158.

[Elchi3]

I'm happy with the release notes we are providing here: https://github.com/mdn/browser-compat-data/releases

I don't think I (we) want to maintain this in a separate file additionally, but thanks for having opened this PR! It prompted us to get a process going for actually doing release notes somewhere :-)