-
Notifications
You must be signed in to change notification settings - Fork 312
Release Checklist
-
Your changes to the library should be on a branch.
-
Your changes should have unit tests.
-
Minify your code using the build script.
./build.sh <google closure compiler.jar path>
-
Run the unit tests in
tests/tests.html
andtests/tests_min.html
and make sure they pass. -
With the mixpanel-js submodule set to your revision, run the dev and min unit tests on Cross-browser Testing for all browsers with a delay of 60 seconds. http://crossbrowsertesting.com https://mixpanel.com/tests/
-
Get a full code review from a Mixpanel developer.
-
Merge your branch into master and push to github.
-
Tag your branch using Semantic Versioning. http://semver.org/
git tag v2.2.1
-
Push your tag to github.
-
Create a release on github that references your tag, and give ot a human-readable explanation for your changes.
-
Create a branch in the mixpanel webapp repo for your JS release.
-
cd
into the mixpanel-js submodule and checkout the new release. -
Run the mixpanel_js_compressor to add the snippet and docs to the repo if they've changed.
-
git commit
the new release to your webapp branch and initiate a full unit test. -
Get a full review from a Mixpanel developer.
-
Deploy the web app.
-
Check https://mixpanel.com/libs/mixpanel-.js and https://mixpanel.com/libs/mixpanel-.min.js to see if they has your most recent revision. The cdn will not immediately update.
-
Compose an email to the engineering team explaining that you released a new revision to the JS lib and notify everyone in chat that they should run the submodule update command after merging in master.
git submodule update --init <mixpanel-js-dir>
-
Compose an email to the Solutions team explaining that there is a new release. They will determine the proper way to inform the community.
-
You're done. Remember that the lib JS files have a 24-hour time to live.