Automate release process #2546

Open
mojoaxel opened this Issue Jan 5, 2017 · 2 comments

Projects

None yet

3 participants

@mojoaxel
Member
mojoaxel commented Jan 5, 2017

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)
@mojoaxel mojoaxel added this to the Major Release v5 milestone Jan 5, 2017
@yotamberk
Contributor

I'll take care of pluging in Travis CI

@Tooa
Member
Tooa commented Jan 5, 2017 edited

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.

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