|
|
This page has three parts: regular releases, beta releases and hotfix releases.
|
|
|
|
|
|
## For releases
|
|
|
|
|
|
### At GitHub
|
... | ... | @@ -63,4 +65,45 @@ This is almost identical, except that we don't do as much. |
|
|
|
|
|
* Send word to the MathJax sponsors
|
|
|
* Announcement should be posted to the User Groups at mathjax-dev and mathjax-users
|
|
|
* The new post should be announced on social media channels [[MathJax-web-presence]]. |
|
|
\ No newline at end of file |
|
|
* The new post should be announced on social media channels [[MathJax-web-presence]].
|
|
|
|
|
|
|
|
|
## Hotfix release
|
|
|
|
|
|
This is the process for releasing a hotfix to the CDN:
|
|
|
|
|
|
1. Prepare and test a branch with the fixes as per our regular development process
|
|
|
2. Merge to master and the release branch at GitHub, e.g v1.1-latest
|
|
|
1. Copy the release branch to `mathjax/x.y-beta` on Cloud Files
|
|
|
1. Test
|
|
|
1. Announce it so people can test against it
|
|
|
1. Send warnings to the cdn-notify list 72 hours in advance
|
|
|
1. Just in case, check the max-age on the current point release directory (e.g. 2.0) and set it to 1h if it's higher. (Background: With Amazon, the usual max-age was 72h and for releases we reduced it to 1h to speed up progagation to CDN-endpoints. Since Rackspace doesn't charge for transfer from Cloud Files to CDN-endpoints, this is set to 15min by default.)
|
|
|
1. Sync the new release to `mathjax/x.y-latest` and `mathjax/latest` on Cloud Files (e.g., Cyberduck can sync folders). Note: renaming/deleting folders on Cloud Files is much slower than syncing.
|
|
|
1. Send confirmation to the cdn-notify list, and update the download page at mathjax.org
|
|
|
1. Monitor for any issues.
|
|
|
|
|
|
We will not attempt to purge the CDN cache for hotfixes, but rather let them propagate normally.
|
|
|
|
|
|
Note that our policy is that we don't tag and package the hot fixes separately. Thus, for example, the v1.1 archive is always the initial v1.1 release, and access to updates for your own server would be through git (by checking out the v1.1-latest branch, which already exists, and will contain the hot fixes), or through the GitHub interface by selecting the v1.1-latest branch in the branch list and then using the Download button there to get the automatically packaged copy. From the [documentation](http://www.mathjax.org/docs/1.1/installation.html#obtaining-mathjax-via-an-archive):
|
|
|
|
|
|
> If a packaged release receives any important updates, then those updates will be part of the branch for that version. The link to the .zip file in the download list will be the original release version, not the patched version. To obtain the patched version, use the Branches drop down menu (at the far left of the menus within the page) to select the release branch that you want (for example v1.1-latest), and then use the download button and the Download .tar.gz or Download .zip button to get the latest patched version of that release.
|
|
|
|
|
|
**Note:** The CDN notify announcements should contain this info, as should the download page.
|
|
|
|
|
|
|
|
|
### Changing Max-Age
|
|
|
|
|
|
> This is mostly for completeness. With Rackspace, the need to change max-age has been eliminated since Rackspace doesn't charge for transfers from Cloud Files to CDN-endpoints. In fact, the default max-age that Cloud Files assigns to uploaded files is 15min. If you need more details, check out an older version of this page.
|
|
|
|
|
|
Changing the max-age for a file requires:
|
|
|
|
|
|
1. changing the Cache-Control header, e.g. Header set Cache-Control "max-age=3600"
|
|
|
|
|
|
The easiest way is to use Cyberduck to set the headers for multiple files, including recursively for directories.
|
|
|
|
|
|
### Doing the Update
|
|
|
|
|
|
In order to avoid to minimize the possibility for corrupting the origin server directories during an update, the preferred method of updating the origin server directories as to prepare the new release in a staging area. This gives us a chance to carefully check the staged files, and avoids exposing a mix of old and new files on the origin server during the time the staged content is prepared. The final sync is not as fast as the old symlink technique (now unavailable), but since the only issue are the png-fonts, syncing is actually very fast.
|
|
|
|
|
|
Of course, that doesn't prevent a mix of old an new files on the CDN servers, since they are only refreshed as they are requests. The strategy for minimizing that period of mixing on the CDN servers is the low max-age settings. Additionally, Rackspace offers CDN endpoint-purges via their support (and for individual files via API). |
|
|
\ No newline at end of file |