Releasing canary versions as commits are made on the `master` branch

Hello everyone!

I have seen many people wanting the new version to be release so they can use some fixes and new features we have implemented but have not yet been released. Especially this one, so I talked to @keithamus on Slack and he had the idea of releasing tagged canary (or beta, whatever you find more suitable) versions as we merge commits on master. We could do this automatically using some CI tooling.

What do you guys think? If we did that people would be able to use the latest features (and they would be aware of that because they would need to explicitly use @canary when installing Chai) and we would also be able to get early feedback on the new things we merged to master. IMO this would be great, it not only improves the quality of the next releases with early bug fixes (related: Boehms Curve) but it would also allow our users to have the latest features they’ve been wanting so bad 😄

If everyone agrees we could also discuss how we’re going to do that, but I think it would be as simple as adding a new target to our makefile which runs an npm dist-tag command when running builds for the master branch (we could detect those builds by using the TRAVIS_BRANCH environment variable).

@keithamus @meeber and anyone that wants to participate, feel free to share your thoughts 👍

[meeber]

Closing this since the Lucas Syndicate successfully released a canary version.

[keithamus]

So to expand:

1. Merge 4.x branch to master.
2. Release as 4.0.0-canary-1 using npm publish --tag canary so users may only install with npm i chai@canary
3. Fix any show-stopper bugs we get, if none goto 6
4. Release as 4.0.0-canary-n where n is last version + 1, still with --tag canary so that npm i chai@canary will get the latest 4.0.0-canary-n release
5. Goto 3
6. Change the version to 4.0.0 and publish with --tag latest (the default tag). 4.0.0 is done, rejoice.