Js-ipfs: Release candidates?

[alanshaw]

We're nearly ready to go with js-ipfs 0.32. I wanted to get peoples thoughts and opinions on adding a step to the release process "Publish a release candidate".

When all the PRs for a release are merged, the usual order of events is to announce publicly that a new release is coming, then after a few days and no blocking feedback the release would go ahead.

This step would come after "Ensure that all tests are passing" and before "Run tests of the following projects with the new release".

So I'd run something like:

npm version 0.32.0-rc.1
# Publish with "next" tag to ensure people still get 0.31.7 when they `npm i ipfs`
# People can also `npm i ipfs@next` to get the latest and greatest
# "next" tag is fairly common - react, redux, hapi all have one
npm publish --tag next
git push origin master v0.32.0-rc.1

I see a number of benefits to doing this:

• When testing against the popular projects and running the examples we can do a proper npm install instead of npm link. Using npm install ipfs instead of npm link ipfs will install only the dependencies. It allows us to catch any missing dependencies or dependencies that have been incorrectly assigned to devDependencies.
• IMHO people will be more likely to install and test out a new release if they can npm install it. The git clone, npm i, npm link, npm link ipfs process is a massive hurdle
• On that same point, we can more easily verify that a release will fix an issue - we simply ask the reporter to install 0.32.0-rc.1. Again I think we'll get more people doing this than the npm link dance
• More people testing out a pre-release allows us to fix bugs and have more stable releases
• It's easier to let people know how to try it out by tweeting npm i [email protected]

The only other thing to mention is that we can't do this with AEgir atm so the CHANGELOG would be untouched - but I think that's ok anyway...

The downsides I can see are this:

• Maybe this is too soon? We're not even 1.0.0 yet, arguably it doesn't matter if things get broken in a 0.x release
• Adds _even more_ process to the release process

Please add a 👍 or 👎 if you think this is a good/bad idea. Ideally if you 👎 then a comment to explain! Thank you :heart:

@ipfs/javascript-team

[alanshaw]

Also worth considering is that npm link isn't the only way to install master - you can also npm i ipfs@github:ipfs/js-ipfs - so it's probably not as big a hurdle as I'm making it out to be above.

[vasco-santos]

I agree with this method!

Moreover, we should guarantee that the ipfs/interop tests do not fail when a new release happens. With this method, we can guarantee this easily without having to go through all the linking and we can have the rule that the final release only can advance if the interop tests are green.

[jacobheun]

While it will add some additional process to the release initially, I think this also sets us up to get much more efficient in the future. If we can add nightly ci builds of key projects to use npm i ipfs@next, this would really help boost confidence in releases and provide us more opportunities to catch failures.

If we wanted to remove some release overhead, we could look at adding an --rc flag or something similar to Aegir, and solely leverage the npm next tag instead of using rc versioning and do the full aegir release. I think the big drawback here is lack of clarity when looking at a version number. The benefit is that when we want to release the version we can just add the latest tag to the live package, which also gives more confidence in that the final published package is exactly the same as what we tested via next.

[achingbrain]

This all sounds great and I am 👍.

We should run the interop tests and do the rc release as part of ci for master though, that'd be 💯, that way only the final non-rc release would be a manual step.

--

Installing from ipfs@github:ipfs/js-ipfs to verify a fix is ok in a pinch but it may have moved on from where you wanted it to be which can cause complications. You also push the burden of figuring out which version (commit?) they have to the user as a simple jsipfs --version won't do it if installed from master.