Releasing canary versions as commits are made on the master branch

[lucasfcosta]

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]

I agree. I make use of this kind of thing in other libraries. For example, in my ES6 projects I use istanbul@1.1.0-alpha.1 instead of istanbul@0.4.4.

[keithamus]

I'm in agreement with this, for now. Ultimately I'd like us to use semantic release so that master is always the released version. Until then this sounds ideal.

[lucasfcosta]

Well, since we all came into agreement, I'll tag this as PR wanted.
I agree with @keithamus, I'd love to use semantic release but for now I think a make target would be enough.
Maybe after we release 4.0.0 it will be a good time to start using that.

[lucasfcosta]

Apparently there is an easier and cleaner way of doing releasing packages within TravisCI itself.
I have found this page on their docs which has the whole explanation on how to do that.

Unfortunately I will need the ChaiJS user's API key for that. Would you mind sending that encrypted key?

With that the rest of the process should be a fast and easy thing to do.

[keithamus]

@lucasfcosta we already have travis deploying on tags: https://github.com/chaijs/chai/blob/master/.travis.yml#L18-L27. We need an automated way to push to npm on master builds, likely using something like:

after-success: test $TRAVIS_BRANCH -eq "master" && npm publish --tag canary

[lucasfcosta]

I just tried to publish a tagged version of a package I own to test this tag feature and apparently it is only possible to publish a new version if we bump its version number. This means we will have to bump Chai version numbers before releasing tagged versions. It is not possible to release version with the same number we already have but with a tag.

Any ideas?
I thought about bumping the patch version number and then using the canary tag, but that wouldn't be exactly "SemVer Friendly".

What do you think about jumping straight to semantic-release?

[meeber]

It should be possible to maintain chai@3.5.0 as the latest version that's installed by default via npm install chai while also having something like chai@4.0.0-alpha.1 available. Never messed with it myself, but that's how packages like istanbul are doing it. This article might help: http://jbavari.github.io/blog/2015/10/16/using-npm-tags/

Given the large number of changes since 3.5.0, I'd prefer finding a way to have a alpha/beta/canary/whatever period prior to switching to semantic-release style.

[lucasfcosta]

@meeber Yes, that's exactly what we will need to do. What I mean is: it's impossible to release a version tagged beta with the number 3.5.0 at the same time.

Each tagged or non-tagged release needs to have a different version number, it doesn't matter if other release with that tag has been published or not.

[lucasfcosta]

Hello guys, so, due to the time I've been away this issue has been idle, so, I was thinking about getting back to it, but I still have doubts about what we should do, because even when using tags we need to have a non-existing version number.

So, what should we do? How are we going to bump version numbers to release a tagged version?
Any ideas?

IMO bumping any version number seems a bit hackish to me, the optimal choice would be to have a different rule to create version numbers for canary releases, since they don't really have a version number, they're just the latest available build.

[keithamus]

@lucasfcosta does #751 (comment) not meet those requirements? We can change the version in the packagejson to something like 4.0.0-canary-1, 4.0.0-canary-2 until we're happy with a 4.0 release, then simply drop the -canary-* suffix and release a proper 4.0.

[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.

[lucasfcosta]

So we're going to release this canary version manually, right?
I just want to confirm this with you since I'm planning on getting a lot of things done this weekend. 😄

[meeber]

I think it's appropriate to release it manually, yes. We can ease into the automated semantic release stuff later.

It looks like we're on the verge of being able to release canary. The open PRs on Chai are basically ready to go. I think the last things to take care of are #737 and chaijs/deep-eql#14. I'm hoping to review the latter within the next couple days, although it looks like there's already a couple known issues.

Am I missing anything?

[lucasfcosta]

@meeber Yes, you're right.
I've made a comment on the RoadMap for us to talk about what we need for 4.x.x and plans to get it done. We can talk more about this there and then come back here when it's time to release a canary version 😄

[meeber]

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