A new release of AMP is pushed to all AMP pages every week on Tuesday. Once a change in AMP is merged into the master branch of the amphtml repository, it will typically take 1-2 weeks for the change be live for all users.
The AMP runtime and extensions are provided through a variety of different release channels. Each channel serves a purpose for developers and for the AMP HTML Project itself. See the release cadence section for a more detailed breakdown of how and when code from the ampproject/amphtml repository makes it into release builds.
To determine if a PR has been included in any of the following release channels, look for the GitHub labels PR Use: In Canary, PR Use: In Production, or PR Use: In LTS (see the section on determining if your change is in a release for more details).
The weekly release channels are considered to be the primary "evergreen" release channels. A green build from the master branch is used to build the experimental and beta release channels; the beta release from the previous week is promoted to the stable release channel (see the detailed schedule).
There are two sets of build configurations used in creating release builds: the canary configuration and the production configuration. The experimental and beta release channels are built off of the same commit. However, the experimental channel uses the canary configuration while the beta channel uses the production configuration. The canary configuration enables experimental components and features that may be turned off in production. It is possible to opt into the experimental or beta channels via the experiments page.
The stable release channel is built with the production configuration and served to most AMP traffic. Since the beta release channel is also built from the production configuration, it represents the exact build which will become stable the following week (modulo the possibility of cherry-picks; see Contributing Code).
The lts release channel provides a previous stable build for one-month intervals. On the second Monday of each month, the current stable release is promoted to lts. This channel is not recommended for all AMP publishers. It is provided so that publishers who wish to perform a QA cycle on their website less frequently may do so by opting specific web pages into the lts channel (see the lts readme).
In the event that the second Monday of the month falls on a holiday, the promotion will be performed after the end of the release freeze.
Important: Publishers using the lts release channel should not use newly introduced features. Because of the longer cycle, the lts release may be as much as seven weeks behind the HEAD of ampproject/amphtml. See the section on determining if your change is in a release to validate if a change will be ready with your chosen release cycle.
Type: Release GitHub issues are used to track the status of current and past releases; from the initial cut, to testing via experimantal/beta channels, to eventual release via the stable and lts channels. Announcements about releases are made on the AMP Slack #release channel (sign up for Slack).
You can determine what changes are in a given build using one of the following:
- The Type: Release GitHub issues for each release build will include a link to the specific release page listing the changes contained in that release.
- The PR Use: In Canary, PR Use: In Production, and PR Use: In LTS labels are added to PRs when they've made it into a weekly or lts build. There may be a delay between when the build is created and when the label is added.
Note: These labels still use legacy release names. They will be renamed soon to reflect the new release channel names (beta and stable).
The AMP Experimental Channel is a way to opt a browser into using the experimental release build of the AMP JS libraries. The Experimental Channel may be less stable and it may contain features not yet available to all users.
Opting into the Experimental Channel is intended for:
- testing and playing with new features not yet available to all users
- using in Quality Assurance (QA) to ensure that your site is compatible with upcoming features of AMP that are still under development
To opt your browser into the AMP Experimental Channel, go to the AMP experiments page and activate the "AMP Experimental Channel" experiment. Please subscribe to our low-volume announcements mailing list to get notified about important/breaking changes about AMP.
The AMP Beta Channel is a way to opt a browser into using the beta release build of the AMP JS libraries that will be promoted to stable during the subsequent release cycle (typically, a week later). It is similar to the Experimental Channel described above, but it will not contain the experimental features that are still under development.
Opting into the Beta Channel is intended for:
- testing and playing with the version of the AMP runtime that will be released soon
- using in Quality Assurance (QA) to ensure that your site is compatible with the next version of AMP
When you opt into the Experimental or Beta channel, you are only affecting the AMP JS libraries in your browser; there is no way to force visitors to your site to use the AMP Experimental/Beta Channel version of AMP.
To opt your browser into one of these channels, go to the AMP experiments page and activate the "AMP Experimental Channel" or "AMP Beta Channel" experiment. Please subscribe to our low-volume announcements mailing list to get notified about important/breaking changes about AMP.
If you find an issue that appears to only occur in the Experimental/Beta Channel version of AMP:
- please file an issue with a description of the problem
- include a note that the problem is new to the Experimental/Beta Channel build so that it can be properly prioritized
- include a URL to a page that reproduces the problem
- ping the AMP Slack #release channel (sign up for Slack) with the issue you filed so we can delay the push of the Experimental/Beta Channel version to production if needed
We are intentionally cautious with our release cadence.
In determining how often we should push new versions of AMP to everyone, we have to weigh many factors including:
- stability for the millions of sites/billions of pages built using AMP
- cache busting that might happen when we push a new version
- the desire to get new features out quickly
After considering all of these factors, we have arrived at the 1-2 week push cycle. Thus far, we have found this to be a reasonable compromise, but we will continue to evaluate all of these factors and may make changes in the future.
We try to stick to this schedule as closely as possible, though complications may cause delays. You can track the latest status about any release in the Type: Release GitHub issues and the AMP Slack #release channel (sign up for Slack).
- Tuesday @ 11am Pacific: new experimental and beta release builds are created from the latest master build that passes all of our tests and are pushed to users of AMP who opted into the AMP Experimental Channel or AMP Beta Channel, respectively.
- Wednesday: we check bug reports for Experimental Channel and Beta Channel users and if everything looks fine, we push the beta to 1% of AMP pages
- Thursday-Monday: we continue to monitor error rates and bug reports for Experimental Channel and Beta Channel users and the 1% of pages with the experimental/beta builds
- Tuesday the following week: the beta build is fully promoted to stable (i.e. all AMP pages will now use this build)
There are occasions when we will skip a release of AMP to production, known as a release freeze.
If a one week release freeze is announced for Week N:
- The previous week's release build remains in experimental/beta for an extra week, i.e. the release cut in Week N-1 is not pushed to stable in Week N as would normally be the case. Instead, it will be pushed to stable in Week N+1.
- A new release build is not made in the freeze week (Week N).
- The normal schedule will resume in Week N+1, i.e. experimental/beta are cut in Week N+1 and promoted to stable in Week N+2.
- If the stable release promoted during Week N-1 was originally scheduled to be promoted to lts during Week N, it will now be promoted to lts on the Monday of Week N+1.
A release freeze may happen due to:
- Times when there are not enough people available to push the AMP release to stable and monitor it. Currently most of the people performing AMP releases are based in the United States, so this will usually be the weeks of the major US holidays of Independence Day (July 4), Thanksgiving (fourth Thursday in November), Christmas (25 December) and New Year's Eve/Day (December 31/January 1).
- An emergency situation, such as a security or privacy issue as determined by the Technical Steering Committee (TSC) or the people performing the release.
- Other situations when stability of the codebase is deemed to be particularly important as determined by the TSC.
In all cases except emergencies the release freezes will be announced at least one month in advance.
Note that unless otherwise announced a release freeze does not imply a code freeze. Code may still be written, reviewed and merged during a release freeze.