Update CHANGES.rst

[hugovk]

Along with #383, fixes #382.

Using this list:

https://github.com/html5lib/html5lib-python/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Amerged+created%3A%3E%3D2016-07-15

[codecov-io]

Codecov Report

Merging #384 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #384   +/-   ##
=======================================
  Coverage   90.76%   90.76%           
=======================================
  Files          50       50           
  Lines        6950     6950           
  Branches     1328     1328           
=======================================
  Hits         6308     6308           
  Misses        483      483           
  Partials      159      159

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 41bd598...6263ec1. Read the comment docs.

[willkg]

This file gets put into the docs and one of the goals I want for it is for users to look at the list of changes and understand how it affects them when they upgrade. This list isn't helpful in that way.

Workflow-wise, it's easier for me to approve your changes and this is a helpful start, so let me write up a comment for this PR that's more along the lines of what I'm thinking of.

[hugovk]

Makes sense.

In general, in future, I'd recommend updating the file as you go along.

Not sure how much this applies to a 1.0 release (probably not at all!), but it may be useful to group things from a SemVer point of view, e.g.

API Changes

• a

API Additions

• b

Other Changes

• c

[willkg]

I want to do something like that, but with headers: "Breaking changes", "Features", "Bug fixes".

In my experience maintaining projects, I've found it's easier to do a rollup at the end just before the release rather than have to deal with getting all the contributors to update the changelog and do it in a way that matches existing releases. I decided that's what I'll do here. Future maintainers can do as they like.

I do appreciate the outline you did, though. That helps a ton!

[willkg]

How about something like this?:

Breaking changes:

* Drop support for Python 2.6. (#330) (Thank you, Hugo, Will Kahn-Greene!)
* Remove ``utils/spider.py`` (#353) (Thank you, Jon Dufresne!)

Features:

* Improve documentation. (#300, #307) (Thank you, Jon Dufresne, Tom Most,
  Will Kahn-Greene!)
* Add iframe seamless boolean attribute. (Thank you, Ritwik Gupta!)
* Add itemscope as a boolean attribute. (#194) (Thank you, Jonathan Vanasco!)
* Support Python 3.6. (#333) (Thank you, Jon Dufresne!)
* Add CI support for Windows using AppVeyor. (Thank you, John Vandenberg!)
* Improve testing and CI and add code coverage (#323, #334), (Thank you, Jon
  Dufresne, John Vandenberg, Geoffrey Sneddon, Will Kahn-Greene!)
* Semver-compliant version number.

Bug fixes:

* Add support for setuptools < 18.5 to support environment markers. (Thank you,
  John Vandenberg!)
* Add explicit dependency for six >= 1.9. (Thank you, Eric Amorde!)
* Fix regexes to work with Python 3.7 regex adjustments. (#318, #379) (Thank
  you, Benedikt Morbach, Ville Skyttä, Mark Vasilkov!)
* Fix alphabeticalattributes filter namespace bug. (#324) (Thank you, Will
  Kahn-Greene!)
* Include license file in generated wheel package. (#350) (Thank you, Jon
  Dufresne!)
* Fix annotation-xml typo. (#339) (Thank you, Will Kahn-Greene!)
* Allow uppercase hex chararcters in CSS colour check. (#377) (Thank you,
  Hugo!)

I think that's sufficiently helpful for users to understand what the changes mean for them. It adds "thank you!" bits for all the people who worked on changes. It adds some/most of the relevant issue numbers.

How does that look?

[hugovk]

Looks good. The original uppercase hex author should get credit too, and in AUTHORS.

[willkg]

@hugovk Can you make those changes to this PR? Then I can review and land it. Thank you!

[hugovk]

@willkg Done!

[willkg]

Yay--thank you!