Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
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.
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.)
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.
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.
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.