Use -stable, -unstable, and -yolo for package pre-release versions across NuGet, MyGet, and CI feeds.

[NickCraver]

With RC1 and limited naming options in NuGet (20 characters and recognized patterns for pre-release) we ended up with rc1-final, rc1-update1 and rc1-update2. While joking about it in Slack chat this morning, better options arose - so I'm starting an issue here for discussion.

The package naming formats we came up were <major>.<minor>.<revision>-<feed/level>-<release>. With the levels being stable, unstable, and yolo (bleeding edge). Here are some examples for a 1.0.1 package:

• NuGet: 1.0.1-stable-#####
• MyGet: 1.0.1-unstable-####
• CI Feed: 1.0.1-yolo-####

When 1.0.1 went RTM, NuGet would just get the 1.0.1 version as it does today. This lets you subscribe to the channel you want even with all the feeds included in the NuGet.config in a very simple way, e.g. 1.0.1-stable-*.

yolo may seem like fun (and it is), but it's also very practical and correct in meaning. The dictionary even defines it as "used especially to rationalize impulsive or reckless behavior"...so that sounds about right.

For RC2, this further avoids confusing issues because we can have 1.0.1-stable-rc2 and, if needed, a 1.0.1-stable-rc2.1 and it just works. I think this is infinitely clearer than what we have right now.

What do others think?

[DamianEdwards]

I really like this. Also note, we could choose to inject -supported as the pre-release moniker prefix for those releases with a go-live license, and it still fits in the required order: stable -> supported -> unstable -> yolo

[DamianEdwards]

NOTE: ### is build number

Here's how this might look for a fictional minor release post 1.0.0 RTM (i.e. 1.1.0):

• dev branches start spitting out 1.1.0-yolo-###
• coherent builds start pushing to myget.org feeds 1.1.0-unstable-###
• once ready for official release it's pushed to nuget.org as 1.1.0-stable-beta1
• process is repeated for subsequent "named" pre-releases (e.g. beta2, rc1, etc.)
• optionally choose to switch to supported moniker when RC is hit 1.1.0-supported-rc1
• finally, final non-pre-release build is pushed to nuget.org as 1.1.0

For patches (e.g. 1.0.1) we don't typically go through the usual named pre-release phases (beta1, etc.), so it might look like this:

• dev branches start spitting out 1.0.1-yolo-###
• coherent builds start pushing to myget.org feeds 1.0.1-unstable-###
• once ready for official release it's pushed to nuget.org as 1.0.1-stable-pre1
• process is repeated for subsequent pre-releases as required (e.g. pre2, pre3, etc.)
• finally, final non-pre-release build is pushed to nuget.org as 1.0.1

[cicorias]

It would be desirable to follow semver so it falls into a natural alpha-numeric sort like:

1.0.0
1.0.0-alpha
1.0.0-alpha.1 
1.0.0-alpha.beta 
1.0.0-beta
1.0.0-beta.11
1.0.0-beta.2
1.0.0-rc.1 

Using your example, this inverts that so the latest is 1st.

1.0.0
1.0.0-stable
1.0.0-unstable
1.0.0-yolo

[NickCraver]

@cicorias In the package case, for example using -*, the absolute latest should win (e.g. yolo). Unless you're using -stable-*, in which case the latest stable feed package wins. That is true of both cases presented, but keep in mind you're comparing different bits here. That's the feed, not the release...but it's in order so it's all in an overall order as well.

I think the big difference here is the first example assumes that the next package in the list comes after the one before...that's not true. We have 3 independent feeds in this case. The alphanumerics you're talking about are the release portion above, which is at the end and remains true/in-order. For clarity, it would be:

1.0.0-stable-alpha
1.0.0-stable-beta1
...
1.0.0-stable-beta96
1.0.0-stable-rc1
1.0.0-stable-rc2
...

Does that make sense?

[cicorias]

it makes sense and I understand the idea of distinguishing different channels, but why not just stick to semantics like 'alpha', 'beta', 'rc' - which are generally unstable, stable, supported.

I guess the reason I say this is that tools such as semver.js don't work on that premise.

[NickCraver]

@cicorias That setup doesn't allow things like people to testing the RC2 release before it hits NuGet for everyone. Since we need to test the entire package system (the whole BCL together) against the feed releases before they progress to the next tier (of feeds). This remains a necessity. The ordering also doesn't (as I understand it) generally allow for named releases that @DamianEdwards notes above.

Binding alpha/beta/rc/etc. to tiers would effectively phase out the nightly tier once reaching the beta phase, and all but NuGet.org once reaching the RC phase. That piece doesn't really work...or am I misunderstanding your intended setup?

[cicorias]

just trying to keep to something that makes it easy to distinguish if i have a lib somewhere on disk, feed, etc. which is really the latest. eg. using semver.js. a version that makes it from unstable to stable feed would also incur a version change as well. The idea that the feed only serves unstable, or yolo already by itself distinguishes it - so why bake it into the name? Then a package once it's OK on unstable and just show up on Stable - and i don't expect anything different.

https://tonicdev.com/cicorias/5738edeff2834f1100264ccd

var semver = require("semver");
/*
1.0.0
1.0.0-stable
1.0.0-unstable
1.0.0-yolo
*/

console.log('result 1: ' +  semver.gt('1.0.0-stable', '1.0.0-unstable')); //sb true
console.log('result 2: ' +  semver.gt('1.0.0-yolo', '1.0.0-unstable')); //sb false
console.log('result 3: ' +  semver.gt('1.0.0-yolo', '1.0.0-stable')); //sb false
console.log('result 4: ' +  semver.gt('1.0.0-stable', '1.0.0-unstable'));//sb true

[NickCraver]

The idea that the feed only serves unstable, or yolo already by itself distinguishes it - so why bake it into the name?

Because one project can pull from multiple feeds. It also allows things like 1.0.0-stable-* to only get stable releases. There's no notion of feed restrictions per package (nor can there be, due to internal proxies, etc.). We have to support more than standalone packages here - we have to support the case of a project of dependencies pulling from many feeds and distinguishing those in a way that works across the board. That's not available at the package level, and such functionality can't be reasonably added.

Today we do something similar to what you're describing with raw semver, and it's a real pain point with every package promotion. The proposed system would even let these pre-release feeds be system-wide and you can very easily opt into what "channel" you want to use with the package name.

As an example, RC2.1 will be available with bugfixes on the unstable feed before it's available on NuGet.org. Do we continue to tell users "add this feed and change it to <package>-rc*"? IMO, that's not very practical and hasn't worked out very well thus far.

[weshaggard]

cc @joshfree @ellismg @ericstj

@NickCraver Thanks for taking the time to post this proposal it is definitely and interesting idea, which I will spend some more time thinking through.

In your original post you hinted that each of these channels would be on their own feed but later in the comments you seem to indicate that they might get mixed across feeds. Correct me if I'm wrong but ultimately I think your proposal would work if all the packages were put into a single feed as well.

From the consuming side is your expectation that each branch (dev, release, etc) would consume a different channel of packages? So for corefx/coreclr master we would consume and produce yolo channel packages? Who do you expect would consume unstable vs stable? What would be a good promotion criteria? Today we generally only have a dev and a release branch so I'm not sure when or how we would prompt through these different channels.