New minor releases should be released as RC versions

[Daniel15]

When we release new minor versions of Yarn (eg. 0.18.0, 0.19.0, etc.), the first release should be released as an RC version number (like 0.18.0-rc.1). This allows people to test the new version, while still keeping the previous release as the stable build. Once we've confirmed that nothing is severely broken, we could then promote that version as the stable version by tagging the same commit as v0.18.0. If any issues are encountered, we'd release a new RC (like 0.18.0-rc.2) and repeat the process. Eventually, some RC would be promoted to stable.

Stuff we probably need to handle:

• Mark GitHub release as "unstable"
• Update AppVeyor release script to handle RC tags / version numbers
• Ensure RC versions are marked as unstable on npm (do we need to do anything manually for this, or does npm automatically handle it based on the version number?)
• Add https://yarnpkg.com/latest-rc-version endpoint for getting latest RC version number
• Add --rc flag to installation script, similar to how --nightly works
• Add separate 'distribution' to the Debian repo for RC releases
• Yarn site should list both the latest version version number as well as the latest RC version number
• Publish RCs to Chocolatey (Publish Chocolatey pre-release packages #2413)

[wyze]

Regarding point 3, it would be published under a different tag than latest. So, next/beta are common, or we could use rc, as long as it isn't the default of latest.

[donaldpipowitch]

I like that! But note that yarn currently has problems with release tags which follow TypeScripts release style as mentioned here #2154.

This is what TypeScript uses:

$ npm i typescript@next
└── typescript@2.2.0-dev.20161205

$ npm i typescript@rc
└── typescript@2.1.1

$ npm i typescript@latest
└── typescript@2.0.10

But yarn sometimes prefers typescript@2.1.1 over typescript@2.0.10 even though it isn't released as @latest, just because 2.1.1 is greater than 2.0.10 semver-wise. It looks like yarn doesn't take dist-tags into account when it compares versions. Maybe every dist tag except @latest should be treated as something like a "virtual prerelease version" so yarn would compare something like 2.1.1-dist-tag-rc to 2.0.10.

npm itself does something similar:

$ npm i npm@latest
└── npm@4.0.3

$ npm i npm@next
└── npm@4.0.5

[wyze]

@donaldpipowitch I was going to look into that bug today.

[donaldpipowitch]

Awesome.

Another question which probably should be solved beforehand is #2077. When @Daniel15 speaks about prereleases like 0.18.0-rc.1 I think he means npm modules with that. Because of #2077 I don't know if yarn should be installable with npm at all. (If it should be installable I wonder why it isn't the default recommended way? I'd guess it would be most common for yarn users.)

[Daniel15]

When @Daniel15 speaks about prereleases like 0.18.0-rc.1 I think he means npm modules with that.

I'm talking about the version number of Yarn itself.

Because of #2077 I don't know if yarn should be installable with npm at all. (If it should be installable I wonder why it isn't the default recommended way? I'd guess it would be most common for yarn users.)

Well, you can install Yarn via npm, it's not recommended though. It's available just in case, for use cases where the other installation methods aren't appropriate or don't work. We do document some of the shortcomings of installing Yarn via npm on the Yarn site now (https://yarnpkg.com/en/docs/install#alternatives-tab "Install via npm" section)

[donaldpipowitch]

Okay. Thank you for the explanation.

[Daniel15]

Mostly done, and there's a separate task for publishing RCs to Chocolatey.