For pull requests:
-
Be consistent with prevelant style and design decisions.
-
Add a Jasmine spec to
specs/q-spec.js. -
Use
npm testto avoid regressions. -
Run tests in
q-spec/run.htmlin as many supported browsers as you can find the will to deal with. -
You do not need to build minified versions.
-
If you would be so kind, add a note to
CHANGES.mdin an appropriate section:Next Major Versionif it introduces backward incompatibilities to code in the wild using documented features.Next Minor Versionif it adds a new feature.Next Patch Versionif it fixes a bug.
For releases:
-
Run
npm test. -
Run tests in
q-spec/run.htmlin a representative sample of every browser under the sun. -
Run
npm run coverand make sure you're happy with the results. -
Arrange for the Google Closure Compiler to be available as a
closurecommand then runsource minifyto buildq.min.jsandq.min.js.gzand commit withMinify.#!/bin/bash java -jar `which closure.jar` $@
-
Note the size of
q.min.js.gzinREADME.mdif it has changed to 1 significant digit. -
Stash any local changes.
-
Update
CHANGES.mdto reflect all changes in the differences betweenHEADand the previous tagged version. Give credit where credit is due. -
Update
README.mdto address all new, non-expiermental features. -
Update the API reference on the Wiki to reflect all non-expiermental features.
-
Use
npm version major|minor|patchto updatepackage.json, commit, and tag the new version. -
Use
npm publishto send up a new release. -
Send an email to the q-continuum mailing list announcing the new release and the notes from the change log. This helps folks maintaining other package ecosystems.