Improve Release Workflow and Introduce CHANGELOG.md

[Mike-E-angelo]

Up until this point we have been using git push --tags to post a new version.

After some research, it turns out we can use GitHub Releases instead. When you post a new release to Releases, a tag is created for you and applied to the most recent commit.

Pretty cool. :)

So we will use releases instead. There's this nifty GitHub app called Next Release:

https://nextrelease.io/

(@WojciechNagorski you should be able to sign in and see ExtendedXmlSerializer let me know if you cannot.)

With this, it will automatically apply commit messages and organize them by Breaking Change (Major), Feature/Enhancement (Minor), and Bug Fix (Patch) along with updating the appropriate next version.

Essentially, the idea is:

• Use Next Release to monitor commits and create a draft release. Once the release is ready, we can publish it on either GitHub or Next Release. This will create a tag and push it to master.
• This in turn fires off AppVeyor which will create a .nupkg package and boomerang back around to add to the release as the release artifact.
• Next, have a GitHub action in place that monitors release creation and editing. There's a gap between when a release is created and when the artifact is applied to it. Unfortunately, you cannot hide a release. So, we will want to create a new Draft release as it is being built by AppVeyor, copying over the information from the currently building release, and delete it. When AppVeyor swings back around with the attachment, it will trigger off another release.editing event which will publish the Draft into the official release, complete with attached artifact.
• But that's not all. 😁 Now that we have the new version, we can send it back over to AppVeyor and update it with the new value. This will save us from manually having to change the value in appveyor.yml with each release and having to remember to do so. Additionally, we can also have the GitHub Action reset the Next build number in settings to 0.
• FINALLY: Once all that is done, the GitHub Action can compile a CHANGELOG.md from all the releases in the history of the contents of created releases. It can then check it into the root of master. appveyor.yml will be modified so that it will filter against this so it doesn't kick of another build.

Once all of this is in place, then the release cycle will be a "one button deploy" experience... as it should be. 😎

[Mike-E-angelo]

Kinda cool:
https://github.com/ExtendedXmlSerializer/NextRelease/releases

GitHub

ExtendedXmlSerializer/NextRelease

Temporary testing repository to test out NextRelease (https://nextrelease.io/) and publishing releases. - ExtendedXmlSerializer/NextRelease