Establish AssemblyVersion to Major.0.0.0 and PackageVersion to be Major.0.0, updates for Release on Tags only as well.

[ericnewton76]

This PR has a general goal of letting S-IO-A to be a lot more stoic. After that, we can then allow TestingHelpers to be more release friendly by splitting out the release cycles between the two libraries.

List:

• establish a release methodology for S-IO-A.
• establish the versioning scheme going forward, by making AssemblyVersion stay static and letting AssemblyFileVersion and AssemblyInformationalVersion float with current release number.
• publish Nuget package on Tag
• publish artifacts to GitHub Release on Tag

Todos:

• 3 digit Nuget PackageVersion (Major.Minor.Patch)
• AssemblyVersion is written as Major.0.0.0 for purposes of simplifying fusion bindings (ie direct DLL references)
• Only on Tag: Deploy nupkg artifacts to Nuget
• Setup github oauth token for deploy artifacts to github releases: https://www.appveyor.com/docs/deployment/github/#provider-settings
• Only on Tag: Deploy artifacts to Github Releases page

Next steps:

• adjust TestingHelpers dependency to Nuget package System.IO.Abstractions@2.2.0
• figure out how to split TestingHelpers into separate release cycles...
• TestingHelpers/TestingHelpers.Tests to separate repo?

I also created RELEASE.md to outline release procedure with the Tags being the kicker for a Deployment

Also, I recommend forcing all pull-requests to develop branch from now on. This way master is always "the latest" when people come looking for documentation, and the master branch will always be whats released.

And split of testinghelpers will invalidate all current pull requests, so we need to work through them.

[ericnewton76]

@jpreese @fgreinacher what do you guys think?

[jpreese]

I'll look this over pretty thouroughly this weekend. I'm actually going to be demoing our "merge into master automatic NuGet package" release approach to a working group on Friday and don't want to change that quite yet.. or it'll kill the demo. But as I've brought up a couple times, I do want to change that.

[fgreinacher]

Thanks for writing this down! I'll try to find some time for deeper thoughts on this within the next couple of days!

[ericnewton76]

"Merge into master" release works, its only problem is identification of the build. Using a Tag approach forces things to stay in sync... release artifacts and the corresponding commit. We could also include more commit information in the AssemblyInformationalVersion part.

Yeah general merge into master for release works fine. If this PR goes in, we'll have that same strategy plus some :)

The biggest part is trying to sidestep the issues with the Net Assembly Binder aka "fusion binder". We're right back to DLL hell with its insistence on precise version numbers. Nuget tries to sidestep the problem by adding a litany of bindingRedirects which works but really bloats out a web.config or app.config. I've been using a strict Major.0.0.0 for the AssemblyVersion which allows for some movement in a SemVer way of upgrading the assembly without breaking bindings and having to write out bidingRedirects everywhere... including further-down projects that might already reference the assembly...

Imagine log4net or NLog using the same approach, and having two different 3rd party assemblies that log using Nlog/Log4net but aren't at the exact same NLog/log4net AssemblyVersion. Bindingredirect handles this, I believe but I was thinking of a smoother approach by having things as Major.0.0.0 permanently in the AssemblyVersion for binding sake. When you break the interface, SemVer says you must increment Major anyways.

[fgreinacher]

I like the general approach here. So here are just the things I don't agree with/am unsure about:

1. While I understand your reasoning for having an assembly version of MAJOR.0.0.0 I prefer consistent versioning between all artifacts. Binding redirects are working pretty much OK nowadays. So I'd suggest to make all versions the same for releases (expect maybe AssemblyInformationalVersion where we could embed the exact commit or something like that.
2. I don't like having complex logic in CI provider configs, so I'd prefer to go for something more csproj-driven. We could use https://github.com/kzu/GitInfo for ensuring consistent versioning without being bound to a single CI provider.
3. I prefer to keep the current branch model (release from master, work on PR branches). As soon as Add SourceLink #326 is merged we don't have to care about matching current NuGet vs current source that much.

[fgreinacher]

@ericnewton76 Most of the changes here are implemented with #369. Can we close this one?

[fgreinacher]

@ericnewton76 I'll close this one. Feel free to create issues/PRs for anything you think needs improvements :)