Changelog update

[rzvxa]

Description of Changes

Closes #1376

New Version Info

Author's Instructions

• Derive a new MAJOR.MINOR.PATCH version number. Increment the:
  • MAJOR version when you make incompatible API changes
  • MINOR version when you add functionality in a backwards-compatible manner
  • PATCH version when you make backwards-compatible bug fixes
• Update CHANGELOG.md, following the established pattern.

Collaborator's Instructions

• Review CHANGELOG.md, suggesting a different version number if necessary.
• After merging, tag the commit using these (Mac-compatible) bash commands:

  git checkout master
  git pull
  sed -n "$(grep -n -m2 '####' CHANGELOG.md | cut -f1 -d: | sed 'N;s/\n/,/')p" CHANGELOG.md | sed '$d'
  git tag -a $(read -p "Tag Name: " tag;echo $tag) -m"$(git show --quiet --pretty=%s)";git push origin --tags

[alerque]

What happened here? Did you start a new branch against an old branch HEAD or something? Perhaps this should be rebased on master, I can't really make out what is going on in the diff ;-)

[rzvxa]

There is a lot happening in this, I would really love a sanity check by you so I accidentally don't break anything.
I've rebased to fc85a6f updated CHANGELOG in a commit, rebased to bce2669 added CHANGELOG update in a commit, rebased to b48b6cf added another commit here, and at last committed a final change log after a7e6749(which is the last commit in the master). As the result every commit reference after fc85a6f has changed, I usually don't do force pushes in open-source projects so I'm not sure if the credits for the commits are kept, in the commit histories GitHub says they are authored by the original author, and committed by me which I'm not sure if is ok or not.

[alerque]

We're not going to force push to the master branch, at this point it has gone out to hundreds or thousands of systems using plugin managers that follow Git HEAD for updates. If you want to backfill the changelog just squash all this down to one commit under your own name. If you want to call out point releases and tag the backdated ones where the features are that's fine, but I wouldn't bother. I would just to one point release based on where master is now and as soon as the changelog is up to speed we can tag it. It can be a multi-bullet point release.

[rzvxa]

I wanted to keep the tags pointing to the right commits with the included changelog. Thanks for pointing out the problem with this, I haven't thought about plugin managers and I'm not sure how they would handle it.
I'll close this PR in favor of a much simpler one with squashed changes.