Automate release process

[keithamus]

When we have a documented release process (#337) we should try to automate it as much as possible.

The ideal solution would be that applying a tag to a commit can create & build a release. That is our goal - but we need to wait for #337 before seeing how far we can get with this.

[lo1tuma]

This should be easy. Travis-ci supports deployments to npm.

[keithamus]

Thanks for the comment @lo1tuma, and you're right - travis supports publishing to npm which greatly simplifies the releasing of modules; however the publish step is a small part of the whole chai release process, which includes building a browser version, updating bower, tagging, updating/deploying docs and more. Let's wait for #337 before discussing this.

[logicalparadox]

I have added credentials into the .travis.yml to support this. If it goes smoothly with the next couple of releases we can also enable this on the dependencies (assertion-error, etc).

The biggest challenge for total automation is the website. While it is mostly static, the plugins list has server-side components which prevents it from being a completely static GitHub-hosted site. Perhaps its time to pay attention to chaijs/chai-docs#34?

[keithamus]

Update on this:

2.1.0 has been released with the travis.yml auto-deploy, which works fairly successfully. Here are some notes about pain points:

• ReleaseNotes.md still needs manual editing - perhaps unpreventable
• Readme.md contributors list needs manual updating, perhaps drop this and just link to https://github.com/chaijs/chai/graphs/contributors
• History.md still needs manual editing - as it is a list of commits, perhaps it is worth dropping History.md, or merging ReleaseNotes.md and History.md (see Get a proper changelog #366 for an example of users being confused by this)
• the three json files (component, bower, package) need updating manually to bump version (perhaps we can automate this with a make task)
• chai.js needs to be generated (if it was just npm we could use prepublish to generate chai.js, but doubt sure if this is compatible with bower/component)
• chai.js version number needs to be changed (we could look at automatically managing this by requiring in package.json, and inlining this for the chai.js build step).

/cc @logicalparadox for thoughts

[keithamus]

Hey @logicalparadox - do you have any thoughts on the above?

[logicalparadox]

I don't have solutions for all of these woes, but if I don't have a solution I can tell you why I did what I did so as to make reasonable decisions about what can change.

• ReleaseNotes.md / History.md - My original intent was to drop History.md when I started the more detailed release notes, but I found it useful as a resource. If it is causing confusion then I see no issue dropping History.md, but perhaps these notes will help make ReleaseNotes.md more maintainable:
  • For ReleaseNotes.md, perhaps its time for a new approach to when it is filled out. Perhaps after a new version is tagged the releaser adds the next section (as 2.x.x or whatever) in the release notes.
  • Contributors doing large feature changes should be responsible for doing a write up in RN before their features are merged.
  • Bug fixes can have the relevant line added by whomever merged the PR, or encourage a write up if necessary.
  • Example: mozilla-services/heka does this, but with less detail than some of our explanations. I like our level of detail.
• README.md contributors was kept because I was also putting on the website resources. Granted, that didn't always happen. If we link to it in both places I am fine with decommissioning this as a manual process.

Other Notes

• lib/chai.js + chai.js inline version number was always meant as a way plugins could provide a single module targeted at multiple chai versions should breaking changes occur between say 1.x and 2.x. But that never happened and plugins don't seem to use it in that way. For now its only use seems to be identifying which version of the browser chai.js you might have manually installed if not using a package management. Very small use case mostly likely. It also made sure that chai.js was committed for every version tag.
• chai.js browser build is currently only ever committed on a version tag. We had issues awhile back with people linking directly to master version and it either being broken or half finished, then opening issues related to features in progress. Also, helps avoid some merging conflicts.
• Browser build was originally done by a custom tool but I switched it to component when deciding to move some features to their own packages.
  • I chose component because it provided the cleanest output at the time. Given its wane in popularity and since browserify has grown in popularity (and has been rewritten since then) it might be time to think about switching. However, if browserify injects unnecessary cruft I rescind this statement.
• While on the topic of external dependencies, there are three packages that we should prioritize switching to over our internal utils. These were extracted so we could provide full test coverage outside of chai's own testing process, which I think you can agree is very good idea.
  • chaijs/type-detect is our full featured typeof replacement. I thought the switch on this one had already been made. Replaces type.js utility.
  • chaijs/pathval provides getters/setters for nested objects and arrays. (expect(foo).to.have.deep.property('bar.baz[2]')). Replaces getPathValue.
  • chaijs/loupe provides object inspection functionality for node and browser. Replaces objDisplay.js and other connected utils.
• Make is still my preferred task tool, and I avoided grunt because I wasn't a fan of their plugin model. Gulp, on the other hand, is very idiomatic/clean, and I would support a change to it if we need to enhance our task running process to support some of the additional changes your pointed out.

Oh, and @keithamus, make sure to add yourself as a contributor in CONTRIBUTING.md.