Prepare 2.8.2 release

[mariocj89]

This updates the changelog for the 2.8.1 release.

Relates-to: #1139

• Update classifiers in setup.cfg to include the latest supported Python
  versions.
• Update the metadata in zonefile_metadata.json to include the latest tzdata
  release from https://www.iana.org/time-zones.
• If necessary, update the tzdata mirror at https://github.com/dateutil/tzdata
• Update NEWS with list of changes:
  • Invoke tox -e news -- --version <NEXT_VERSION>
  • Make sure that only template.rst remains in changelog.d/
  • Manually clean up the new NEWS file.
  • Replace entries in the "Misc" section that are not likely to be
    interesting to anyone consuming the package (e.g. changes to CI) with
    a reference to the Github PR.
• Commit the changes in git and make a pull request.
• Follow the "Releasing" steps below

[mariocj89]

@pganssle for " If necessary, update the tzdata mirror at https://github.com/dateutil/tzdata" it's just tox -e update, isnt it?. But is that relevant given that nowadays we have python/tzdata? Is the dateutil/tzdata used at all?

[pganssle]

@pganssle for " If necessary, update the tzdata mirror at https://github.com/dateutil/tzdata" it's just tox -e update, isnt it?. But is that relevant given that nowadays we have python/tzdata? Is the dateutil/tzdata used at all?

IIRC it's a little more involved than that, because you need to update the dateutil/tzdata repo. I think I set that up as a mirror because the old location we were pulling from was not so reliable, but as you say when we switch to using the tzdata PyPI package none of that will be necessary anymore, and I don't know that anyone is using updatezinfo.py right now other than us.

In any case, it's currently up to date anyway.

[pganssle]

Looks like we generally use RST syntax for this file, and past tense ("Fixed" rather than "Fix").

I tend to prefer to roughly arrange the news from "most likely to affect people" to "least likely to affect people", within their categories. Obviously this is very subjective, but it may be worth looking at the list and re-arranging it. Other than the stuff I noted I didn't really go through and try and figure out the best order (and obviously not worth spending much time on it).

[mariocj89]

Should be ready now for another review @pganssle

[pganssle]

LGTM.

I made two minor changes and force pushed an amended cleanup commit.

I think that if you want to trigger the test PyPI CI job, you're going to need to push this to a branch on the dateutil/dateutil repo, not your own fork, because the "manually trigger an update" CI workflow only seems to allow selecting branches, not PRs.

Alternatively pushing a 2.8.2.dev0 tag for this PR would work as well.

[mariocj89]

Cool ! I land, tag, test the release and then create the release in github.

[mariocj89]

There seems to be an unrelated failure in appveyor. I'll land and troubleshoot if it happens in master.