Draft of RichWidgets release process

richwidgets-release-process.adoc

Prerequisites

Environment

Node

0.10.21

Notify Development Team

The person performing a release should post a message to the #richwidgets channel on irc.freenode.net.

Review Issue Tracker Status and Continuous Integration

Before starting any release steps, make sure the continuous integration builds pass and that all issues scheduled to particular version are resolved.

Issue Tracker:

• RichWidgets issue tracker on GitHub

  • select appropriate milestone

Continous Integration builds:

• Travis CI - master branch continuous integration

  • need to pass at 100%

• CloudBees/SauceLabs - browser compatibility matrix

  • these jobs should pass on all supported browsers at 100% during candidate releases

  • they does not have to fully pass during alpha releases

Finish Release Notes

dist/release-notes.adoc should be updated before starting with a release.

Release Staging

1. Make sure all respected commits are committed in master branch.

2. Diverge a branch stage from the latest commit on master branch (this is a branch used for release testing)

3. Change version of the project in bower.json and package.json to release version (drop -wip suffix)

4. Build a distribution in dist/ directory and add it to the repository using git add -f dist/

5. Push the stage branch upstream, making it available for release verification

Release testing

At this point the release is prepared for testing by QE team.

What needs to be verified:

• all tests pass on all supported browsers

Creating and Pushing Tag

Once the release pass QE criteria:

1. Create a tag from latest commit on a stage branch, call the tag by a release version: e.g. 0.2

2. Push the tag to upstream repository

3. Remove dist/ branch

4. Change version of the project in bower.json and package.json to development version (drop -wip suffix)

5. Merge stage branch (that includes the tag) to master branch (so that it appears in master branch history)

6. Drop a stage branch

Releasing

1. Create a Release in GitHub interface

2. Attach a built ZIP distribution (snapshot of tag sources that include built dist/)

Release verification

• the ZIP can be downloaded from GitHub Releases view

• the tag can be downloaded via Bower

Drawbacks:

• we push a branch before it is verified - it might be better to create a temporaty tag/branch for QE purposes - e.g. 0.1.cr1

Let's add some links for the CI build status and the issue tracker.

Also, the version strings in bower.json and package.json need to:

1. drop the wip suffix prior for the commit which will be tagged (if multiple commits have this version number in the json files that's fine)
2. increment the version number on the master branch post release, adding back the wip suffix.

Brian, I have worked in you suggestions.

• +1 for creating a release branch. IMO we could recycle a generic name like stage for each release, and merg/remov the branch after each release. There is no need for a release specific name in the branch. This would make CI tools and release processes easier to use.
• The project version is in both the bower.json and package.json files. These either both need to be updated, or we should remove the version string from the one that is not being updated.

Okay, I have updated the process so that it works with stage branch concept:

most significantly, the release has two phases:

1. Release staging
2. Release tagging

We work with stage branch separately from dist branch and we merge it back to master, in order release tag to appear in master branch history.

Brian, can I merge it to RichWidgets at this point?