-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Release Instructions Checklist
-
Do final merges and checks
-
Update URL of demo code in:
- docs/about/getting-started.html
- docs/pages/page-anatomy.html there are two paragraphs in that document that need to be updated
- docs/pages/page-template.html
- docs/pages/multipage-template.html
-
Update docs/pages/page-anatomy.html JQM and jQuery core versions in the text paragraph
-
Update docs/about/getting-started.html JQM and jQuery core versions in the text paragraph
-
Update supported platforms in docs/about/platforms.html
-
Update version in README.md
-
Update version.txt to stable version information for this release. This is important as jquerymobile.com uses this to build the /demos/release-version and redirect both /demo and /demos to the correct area.
-
On a system with access to both CDN and jquerymobile.com, use the script "make deploy". This will build the necessary JS and CSS files (minified and full). It will copy them to the CDN. Then it will create the demos and copy that to jQueryMobile.com/demos/release-version
-
Git add version.txt and commit it
-
Git push to the master branch
-
This will trigger the jquerymobile.com/test and code.jquery.com/mobile/latest to update
-
Before or after this process, do a blog post detailing the changes
-
Change the version number and links on the homepage (intro link, linked devices, demo link)
-
Update Demos & Docs link in top nav
-
Update CDN links on Download page
-
Update version and supported browsers on Platform page
-
Make sure the ribbon for the demos with the release number displays correctly (value and format)
-
Make sure the docs footer displays correctly (value)
-
Upload release to Microsoft CDN
To perform a test deploy:
- change the version in the `package.json`` file
grunt deploy
This assumes that you have the keys to code.jquery.com
, if that's the case then:
grunt release --releaseBranch=<current-branch> --releaseVersion=<version-to-release>
This will assert:
- that you're on the branch you say you want to release from
- that your workspace is clean of any pending modifications
- that you're not attempting to release a pre version
Once all theses checks have passed it will:
- Change the
package.json
version to the one specified in thereleaseVersion
parameter - Commit the version change
- Tag the repo with
releaseVersion
- build the library and demos
- Deploy them to the CDN
- Change the version to
releaseVersion + ( patch + 1 )``pre
- Commit the version change
NOTE: The last step is manual
You still need to push manually to the central repo.
When a new year comes, the following files need to be updated:
- LICENSE-INFO.txt
- MIT-LICENSE.txt
- tools/log-page-events.js
- tools/page-change-time.js
- All the pages in the docs folder (footer)
- Index.html (footer)
- /test is the latest unbuilt test files and demos. It is a git clone with one modified file in it: gitpushlatest.php. This file is altered so it just pulls the latest updates from Github
- /githook is used to build the nightly and latest files on the CDN. It is an unaltered clone.
- Both /githook and /test receive a post commit ping from github whenever there is a new push to the master branch.
- /demos contains the past stable releases
- /demos and /demo, when visited directly, will redirect to the latest stable