Guidance for release channels #69
Description
People try to do the right thing using Semantic Versioning (semver.org) and applying Continuous Delivery practices. However, it's easy to get stuck without proper guidance, as MyGet is flexible enough to support multiple scenarios.
We should provide guidance on:
- when to push upstream (e.g. publish to nuget.org)
- how to set up various release channels by using multiple feeds
- how to configure MyGet Build Services (convention-based, and scripted)
Example of a scenario we want to explicitly avoid with this guidance:
A package publisher is doing continuous delivery to a single feed for all branches. Following semver, the package publisher is applying proper prerelease tags (e.g. which include the branch name, or a quality label). However, this is not obvious for package consumers connecting to that single feed, as the client tools will not understand the publisher's intent. E.g.: when a package consumer wants to upgrade an already installed package 1.0.0-dev-20170401, and a package with version 1.0.0-issue42 is available on the feed, the client tools will see that package as an available upgrade whilst in reality you've just switched branches...
That's where release channels come into play, which can be set up by configuring e.g. a dev or integration feed, a nightly feed, and a production feed. Any of these can be on MyGet, or upstream. NuGet.org should be considered a production feed in all cases.