Proposal - Release strategy

After #95 closing #45, It should be great to:

• publish the package on https://nuget.org/.

• update the package frequently

• make "strict" use of semver http://semver.org/, incrementing semver based on breaking change (=major), incrementing feature (=minor) bug fixes (=patch). For example, node.js haven't received any breaking change till date (current stable version is v0.12.3)!

• publish the release on GitHub: https://github.com/Microsoft/msbuild/releases highlighting the changes since previous version and to let user install the package from source like so:

  Install-Package MSBuild -Source https://github.com/microsoft/msbuild/archive/v0.1.0.zip

  (assuming MSBuild does not have its own versioning, now would be an excellent time to start fresh with semver)

Additional notes:
The releases by GitHub get the "release assets" stored in Amazon S3. The .tar.gz and .zip files are automatically generated and uploaded by GitHub. You can manually add more files as release assets by editing the release. Ex. https://github.com/microsoft/msbuild/releases/edit/<version>, scroll down where it says Attach binaries by dropping them here or selecting them or even using GitHub API.

[akoeplinger]

I think putting the package on nuget.org is what's planned anyway and I agree that having release notes on GitHub would be great :)
The -Source parameter in your example doesn't make sense, it needs to be a nuget feed (and I don't get what benefit this would have over nuget.org?).

For example, node.js haven't received any breaking change till date (current stable version is v0.12.3

Sorry to be nitpicky, but that's just not true, 0.x is explicitly exempt from this rule in semver:

1. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Thanks @akoeplinger for the correction! I didn't knew about that. :)

The -Source option is normally used for installing the package from local drive. If it allows network paths (such as http and https URIs), it would make sense to fetch from GitHub URL and build MSBuild, since MSBuild is now hosted on GitHub, IMO that example would make sense in certain scenarios, for instance, if you are writing the example CLI script in docs, you would probably like to have a step Install-Package MSBuild -Source https://github.com/microsoft/msbuild/archive/master.zip). This is analogus to npm install Microsoft/typescript which fetches from GitHub slug's latest master (without even specifying the full URL). This is one of the benefit of having true RESTful URLs (which we miss in VSO on daily basis..)

[akoeplinger]

@jasonwilliams200OK What I meant was that this is not something NuGet currently supports with the -Source option (it needs either a NuGet feed or a drive/folder with .nupkg's). But that's offtopic ;)

[AndyGerlicher]

This is something we do want, but not something we're planning to do in the near future. This is definitely a core scenario when we are planning the vNext.

[Sarabeth-Jaffe-Microsoft]

We are now publishing our packages on NuGet: https://www.nuget.org/packages?q=microsoft.build

You can grab specific releases under: https://github.com/Microsoft/msbuild/releases

Official release notes would be under Visual Studio: https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes

note that the package in question is here:

http://nuget.org/packages/Microsoft.Build.Runtime

[rainersigwald]

@svnpenn Which package you want to reference depends on what you're planning to use MSBuild for. In most cases, you probably don't want Microsoft.Build.Runtime. https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application has additional information.