Automate release process

[mojoaxel]

We really need to do something about the release process of this library!
There is way too much manual work required to create a release. That is why canches bulk up and then releases even get harder to do.

Let's think about what we can improve..

Thinks we should/could automate:

Automatic test (travis-ci)

• Did any of the existing parameters/options change => Breaking change. This could be done checking e.g. the optionsTimeline.js for deletes or changes (additions are ok).
• checkout if the examples are still running after npm install
• checkout if the examples are still running after bower install
• Do the examples still run without any error on the console (e.g. phantom.js can monitor console outputs).
• Do (reproducable) examples still produce the same screen-output (using e.g. wraith

Automate the release

• Get the commit-history since the last tag from git and append it to a changelog.
• Auto-bump up the version using e.g. semantic-release. This would require a strict guideline for commit messages!
• Create a release on github using the changelog and the new version.

Update the gh-pages branch after each new release:

• copy the dist folder from the recent master branch.
• copy the docs folder from the recent master branch. (In future maybe even generate the docs from source comments!?)
• copy the examples folder from the recent master branch.
• generate the example-overviews using all existing examples and images. For examples that not yet have a preview-image a default.image should be used, that can be replaced later on.
• Update the library version number in the index.html page.
• Update the CDN links at the download section of index.html AND the CDN link at the top. (replace all)

[yotamberk]

I'll take care of pluging in Travis CI

[Tooa]

We could automate the changelog generation process similar to the angularjs team. They have restrictions for their commit messages (reference). You can then check whether the commit message meets the criteria with Travis by running a script like this. Even better if we use a git commit hook that checks the message before the commit.

This allows us to generate the changelog automatically. See here. The result looks like this. What do you think?

Edit: I just realized that the git changelog procedure is already described in the first post, sry.

[mojoaxel]

One of the big problems is that we are not merging develop into master but rebasing master on develop. We need this at the moment because of the following things:

• The dist folder does not get ignored in master but develop
• The dist version should not generate source maps

We need a solution for this dist folder thing!

[macleodbroad-wf]

Can we break this up into separate issues, and give them a tag like: "Release Process" ?

Also, I'm wondering if we can use https://github.com/graphcool/chromeless instead of wraith and/or phantom?