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 to be live for all users.
The AMPHTML Validator has it's own Release Schedule
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 nightly release channel is updated (as its name indicates) every weeknight. This process is automated, and there is no guarantee that any given nightly release is free of bugs or other issues. Each night after midnight (Pacific Time), the last "green" commit from the day is selected to be the release cutoff point. A green build indicates that all automated tests have passed on that build.
The nightly release provides a mechanism to detect and resolve issues quickly and before they reach the more traffic-heavy weekly release channels. It also serves to reduce the number of users affected by newly introduced issues.
It is possible to opt into the nightly channel, to test pull requests that were merged in the past few days. See the opt-in section in [DEVELOPING.md] for details.
The weekly release channels are considered to be the primary "evergreen" release channels. Each week the beta release from the previous week is promoted to the stable release channel, and the last nightly release from the previous week is promoted to the experimental and beta release channels (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 (with the possibility of cherry-picks to fix last-minute issues; see Contributing Code).
The Beta and Experimental Channels are pre-release candidates for the next Stable release of AMP. Every Tuesday (except for weeks where there is a release freeze), last week's nightly is promoted to the developer opt-in channels for beta and experimental. Following a 1-day period where we verify that no feature or performance regressions were introduced in these channels, we promote this release on Wednesday to a small portion of traffic. This same release is then promoted to the stable channel on Tuesday the following week.
It is possible to opt into these channels. See the opt-in section in [DEVELOPING.md] for details.
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
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
The Experimental Channel may be less stable and it may contain features not yet available to all users.
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).
If 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 experimental/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 Beta / Experimental, PR Use: In Stable, 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.
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).
- Every weeknight: a new nightly build is automatically cut and released to the AMP Nightly Channel.
- Tuesday @ 11am Pacific: new experimental and beta release builds are created from a recent known-good nightly channel release and are pushed to users 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.
- nightly releases are still generated and promoted, as they are fully automated.
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 the 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.