Deploy only from release branch

[fgreinacher]

The overall idea I have is to trigger Nuget.org push and GitHub release creation by merging changes from master to release via a PR. This will reduce the number of GitHub releases and package versions on NuGet.org. Also I hope that AppVeyor will then be able to create release notes containing all changes since the latest release.

Thoughts?

[fgreinacher]

OK, this is now ready for 👀

[fgreinacher]

@jpreese @robkeim @ericnewton76 Could you have a look? I'd like to deploy 3.0 (#408) and would like to have this in (or out 😄) before.

[robkeim]

This change looks good to me although I'm not a CI ninja.

[ericnewton76]

Sorry to come late to this party.

I've found to generate a release with a new tag is best. A new tag push indicates an actual release, and the release version is directly dictated by the tag.

Triggering a release from a branch commit creates chicken and egg problem with the release version... Its difficult to lock down the actual release version without a tag.

[fgreinacher]

No worries for being a bit too late :)

I don’t know if I understand what you describe as the chicken and egg problem.

Version generation is driven solely by commit history (through Nerdbank.GitVersioning). This logic is not influenced by tags. So, building the “same” commit again would still produce the same version, irrespective of how the commit is referenced. When a CI build is ran on the release branch, AppVeyor will automatically create a GitHub release (and therefore also a tag) and push the package to NuGet.org. The GitHub release notes will contain all the commits included in the „release PR“, so it should be easy for consumers to see what has changed.

So yes, we cannot „lock down“ the version, but to me that doesn’t seem to be important as long as we (and consumers) know what’s in the release.