One of the main benefits of using AMP is its evergreen release. Today, web developers and engineering teams can get the best of what AMP has to offer every week without being burdened by dependency management.
Over the past few months, the Infrastructure Working Group has been working hard to improve the way AMP releases its runtime and components. The improvements are based on the following feedback:
- Some development teams prefer a slower release cadence so they don’t have to run Quality Assurance (QA) for their website every week.
- Existing documentation for AMP releases can sometimes be incomplete or confusing.
- It’s essential to be able to detect potentially breaking changes before they reach the majority of end-users.
- Some partners would like to be able to self-host the AMP runtime and components during development instead of having to fetch them from cdn.ampproject.org.
The goal of this blog post is to help the reader understand how AMP releases work today, and to learn about upcoming improvements (like updated release channel names, the LTS and Nightly channels, and the ability to self-host AMP on origin URLs).
Understanding AMP Releases
A new version of the AMP runtime is released each week. In order to create confidence in the fact that publishers’ websites will look and behave the same, releases are provided via multiple channels. The main release channels are called Stable, Beta, and Experimental. They serve different purposes, and are seen by different population sizes. In addition, we’re introducing two more channels called LTS and Nightly to further aid in testing and maintenance. Here is a brief description of each channel.
Stable Channel
This is the main production-ready release channel for the AMP runtime, and is used by the vast majority of AMP documents. When a change is submitted to the AMP codebase, it goes through multiple layers of testing and verification via other channels before becoming part of the stable channel.
Beta Channel
The beta channel is an accurate representation of the upcoming stable channel release. Developers and QA teams may opt in to the beta channel in order to verify their websites against the latest changes to the AMP runtime. This can be done by opening the AMP experiments page in a browser and activating the “AMP Beta Channel”.
Note: Opting in to the beta channel will only affect the version of the AMP JS libraries used in your browser. There is no way to force visitors to your website to receive the beta channel version of AMP.
The beta channel may be less reliable than the stable channel, and may contain features not yet available to all users. It is intended for:
- Trying out a new AMP feature that will be released the following week.
- Performing QA to verify that a website is compatible with the next version of AMP.
Experimental Channel
Some new AMP features can take multiple weeks to develop and test. As a result, they are hidden behind experimental flags that are turned off in the beta and stable channels. The experimental channel provides developers and QA teams with a way to try out and test new features. This can be done by opening the AMP experiments page in a browser and activating the “AMP Experimental Channel”.
Note: Opting in to the experimental channel will only affect the version of the AMP JS libraries used in your browser. There is no way to force visitors to your website to receive the experimental channel version of AMP.
The difference between the experimental and beta channels is the fact that some features that are in development may be available in experimental, but turned off in beta. If a feature is considered ready for use, its flag is turned on, making it visible in the beta channel, and eventually, the stable channel. Depending on the feature, this could take days, weeks, or even months.
Long Term Stable (LTS) Channel
A recurring request from developer teams has been for an AMP release channel with longer intervals between versions in order to allow for a longer QA cycle than the current weekly cycle.
The newly created Long Term Stable (LTS) release channel solves this problem. Approximately monthly, a recent stable channel release is promoted to the LTS channel.
It’s important to note that the LTS channel is not recommended for all AMP publishers. It is provided for those who wish to test their websites less frequently, and are okay with waiting a few weeks before using new features. Publishers may opt to use the LTS channel for specific pages on their website. Webpages using the LTS channel will get the same cache benefits as with the stable channel.
Unlike the beta and experimental channels which individuals can opt in to by setting a browser cookie, the LTS channel is served to all users of a webpage when the publisher opts to use it for that page.
A new LTS version is made available on the second Monday of each month by promoting the previous week’s stable channel release. The schedule for the LTS channel can be found here.
Using the LTS Channel for a Webpage:
Here’s an example of a webpage that uses the stable channel:
<script async src="https://cdn.ampproject.org/v0.js"></script> <script async custom-element="amp-ad" src="https://cdn.ampproject.org/v0/amp-ad-0.1.js" ></script>
To use the LTS channel instead, simply change the “src” attribute for the runtime and extension scripts as follows, by adding “lts/” to the URL:
<script async src="https://cdn.ampproject.org/lts/v0.js"></script> <script async custom-element="amp-ad" src="https://cdn.ampproject.org/lts/v0/amp-ad-0.1.js" ></script>
Note: You should ensure that the AMP runtime and extension scripts you are using are on the same channel to make sure your AMP document is valid. For example, using v0.js from the LTS channel and amp-carousel-0.1.js from the stable channel will result in a validation error.
Nightly Channel
In order to increase confidence in the quality of upcoming AMP releases, we will soon automatically generate nightly builds of the AMP runtime, and make them available via a new Nightly channel. This channel will help reduce error rates, improve runtime performance, and ensure overall code quality. Code from the nightly channel will eventually make it into the beta / experimental, stable, and LTS channels. Once it is introduced, developers will be able to opt in to the Nightly channel in the same way that they can opt in to experimental or beta, as described above.
Note: We do not encourage developers to opt in to the nightly channel unless they wish to test changes daily, as it is less stable than the beta, experimental, and stable channels.
Release Schedule
The section above went over all the existing and upcoming release channels. Let us now follow the journey taken by a piece of code from when it is submitted to the open source repository via a pull request, to when it makes its way through the various release channels.
Suppose a piece of code is merged to the open source repository on the 8th of a given month (N). Since this happens to be a weekday, the following nightly build (the 9th) will include the code. After a few days of testing, on Tuesday the following week (the 16th), users can see the code by opting in to the beta or experimental channels. Assuming no issues are discovered, the code will make it to the stable channel the following Tuesday (the 23rd). Finally, on the second Monday of the following month (the 16th of month N+1), the same stable channel release will become the new LTS channel release.
You can read more about AMP’s release channels and schedule at the project’s release schedule page. You can also visualize the process by which new code is merged into the amphtml GitHub repository progresses through time to reach publishers, developers, and end-users.
A New Way to Self-host the AMP Runtime
We are currently working on making it possible for website owners to self-host the AMP runtime, without breaking AMP validity. The benefits are:
- Independence: The AMP runtime and components no longer need to be loaded from https://cdn.ampproject.org for AMP pages served from an origin URL.
- Control: Websites can align the roll-out of a new AMP version with their own QA. They can also rollback to a different version of the AMP runtime whenever the need arises.
- Performance: Faster page load and TTI by avoiding an additional HTTPs connection.
The goal is to allow publishers to link to a self-hosted version of the AMP runtime without breaking AMP validity. This means the following will be valid AMP:
<!DOCTYPE html><html amp transformed="self;v=1"> <head> <script async src="https://example.com/amp/v0.js"></script> <script async custom-element="amp-bind" src="https://example.com/amp/v0/amp-bind-0.1.js" ></script> ...
Note: In order to preserve user privacy, AMP Caches will not support runtime self-hosting and instead will rewrite links to the cache hosted scripts.
The plan is to launch AMP runtime self-hosting later this year and you can follow the implementation via the intent-to-implement and the design doc.
* * *
With all these changes, we hope AMP releases are easier to understand, adopt, test, and deploy. Our thanks go out to you, the AMP development community, for your work and feedback. As always, please let us know if you have any issues or feature requests.
Posted by Naina Raisinghani and Raghu Simha, AMP Project