Release Process

Test

A release should be well tested.

At the minimal, it should build locally (which includes QUnit tests), pass manually testing and pass travis-ci. Archives built by the local build should be manually inspected.

While we should continue improve test automation, manually testing should always be performed.

Build

First, ensure the version number in << jQT's root>>/package.json is up to date. All changes should be git committed (including the version number), but not necessary git pushed at this point.

The release candidate can be generated by running the following commands:

npm install 
grunt dist
# See, project README.md for env setup details 

Two archives are being built by the script above: jqt-<< version >>-<< githash >>.tgz and jqt-demo-<< version >>-<< githash >>.tgz. The are placed under << jQT's root>>/archive.

The first (dist) archive contains the bare minimal:

• jQT's js scripts
• jQT's css and images
• jQT's extension, and
• any custom built dependencies (zepto.js)

The second (demo) one includes everything in the first package, plus:

• Depended script (jQuery)
• jQT's demos

(In future release, we should consider including QUnit tests in the second archive.)

Manual testing

The release candidate are being built into << jQT root>>/archive/package directory. Manual testing should be performed under that directory.

The demo should be manually tested on both a desktop webkit browser and on a iOS device

The demo should be served over HTTP for iOS device. The demo should be served both locally with file protocol and over HTTP for a webkit desktop browser.

All buttons or links should be tap on. All demo reachable from the main demo should also be tested.

The test should be performed on all theme available from the main demo.

Inspect the archives

The two archives should be untar and unzip and be manually inspected. Demos in the demo archive should be opened. Each files in the dist archive should be opened with a text editor.

Travis-ci

If the release candidate builds locally and passes local test, it should be pushed to the master branch on github.

git push origin master

Travis-ci will pick it up automatically. Wait until this is completed.

Release

If all tests passed, a release tag (based on the version number defined in package.json) can be created by running. After the release tag is created, the archives can be regenerated with the correct name.

grunt git-tag
grunt dist

To make it public, perform:

git push --tags  # or, do $ git push origin <<tag name>> to avoid local tag being pushed.

Now, we can create a release in github page and add details.

The two archives generated earlier can be uploaded to the github's release page. Ensure the githash of the archive matches the githash of the tag.

Done!