Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Releasing canary versions as commits are made on the master branch #751

Closed
lucasfcosta opened this issue Jul 14, 2016 · 15 comments
Closed

Comments

@lucasfcosta
Copy link
Member

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
Copy link
Contributor

meeber commented Jul 14, 2016

I agree. I make use of this kind of thing in other libraries. For example, in my ES6 projects I use [email protected] instead of [email protected].

@keithamus
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

keithamus commented Jul 18, 2016

@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
Copy link
Member Author

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
Copy link
Contributor

meeber commented Jul 20, 2016

It should be possible to maintain [email protected] as the latest version that's installed by default via npm install chai while also having something like [email protected] 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
Copy link
Member Author

@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
Copy link
Member Author

lucasfcosta commented Aug 23, 2016

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
Copy link
Member

@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
Copy link
Member

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.

@keithamus keithamus modified the milestone: 4.0 Sep 6, 2016
@lucasfcosta
Copy link
Member Author

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
Copy link
Contributor

meeber commented Sep 28, 2016

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 lucasfcosta mentioned this issue Sep 28, 2016
10 tasks
@lucasfcosta
Copy link
Member Author

@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
Copy link
Contributor

meeber commented Nov 25, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants