AMP Release Schedule (original) (raw)

Documentation Guides & Tutorials

A new release of AMP is pushed to all AMP pages every week on Tuesday. Once a change in AMP is merged into the main 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

Release Channels

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).

Nightly

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.

Weekly

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).

Beta and Experimental channels

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:

The Experimental Channel is intended for:

The Experimental Channel may be less stable and it may contain features not yet available to all users.

Long-Term Stable (lts)

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.

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.

Determining if your change is in a release

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 release using one of the following:

Release Cadence

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:

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.

Detailed schedule

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).

Release Freezes

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:

A release freeze may happen due to:

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.