Amphtml: A Stable Version of AMP

[leonalicious]

Describe the new feature or change to an existing feature you'd like to see

Understand AMP is an ongoing project and is aimed to provide more and richer components/ features to the users but as the development moving on, it is unavoidable that some of the components that are working fine now, will not be working in future with the latest version released.

As AMP Community is getting bigger and components are more mature (lesser bugs), we are hoping to have some version controlling mechanism, such as if the developer is comfortable with a particular version, the developers may have the option not to UPGRADE until there are new features which may be helpful and attract the developers to do so.

Describe alternatives you've considered

Two approaches which I can think of

1. If AMP Team is concerning about large numbers of versions are difficult to be maintained, may set the release lifespan a little bit longer, such as a stable version every 3 months, and developers may do a Full Cycle Test every 3 months before adopting the new version, and any Stable version will only be maintained for a certain period, and be replaced by any newer version.
2. Token Mechanism, <meta name="amp-experiment-token", not too sure how this works but sound this meta tag can determine current domain which binds to a certain version of JS script for specific feature

Thoughts ？

/to: @aghassemi @choumx

[aghassemi]

Thanks for the write up @leonalicious adding @ampproject/wg-infra and @ampproject/tsc to discuss.

[cramforce]

I'm open to entertaining changes in this direction. We've been looking at increasing time-to-release for changes while simultaneously reducing time-until-code-changes-get-very-limited-prod exposure, so that everybody has more time to manually test and the time until problems are found go down.

Another related proposal is self-serve-JS-on-origin which could be used to version lock to some extent (but doesn't imply version locking on cache serving).

Possibly a thing we should try is to allow publishers to opt-into the last 1-2 versions and see if that is something people want. Whatever approach we'd take, it should not give up the evergreen-ness of AMP.

[torch2424]

If I may,

Spoke about this with @lannka , we both agree this is a good idea. It would be rad if they could just include a meta tag in the head or something for an "LTS" version.

I guess this was brought up in the past under the idea that if we offered this, everyone would just use the LTS version of AMP. Which I disagree with. I imagine a lot of people who have very simple amp pages / features on things like their landing pages will probably opt-in to stable. But once they need newer features on specific AMP documents on their site like amp-consent-v2, amp-recaptcha-input, amp-script, etc... they will need to go out of stable in order to use these newer features and preserve the "evergreen-ness of AMP". Thus giving publishers the option of protecting their more business critical parts of their app, while also trying the latest and greatest in production on sites that need it.

I also wouldn't expect smaller AMP pages to opt-in to an "LTS" as one-off or small blogs that use AMP, probably won't notice / care that there is an LTS as long as the website works.

I kind of see it like flavors or Ubuntu. I would run the LTS on my servers, but stable on my personal machines and anything that happens to need the latest feature.

But that is all just my opinion. Hopefully someone finds this useful!

[cramforce]

I prefer finding analogies in Chrome releases than more classical release streams. I think the thing we want to keep as a property is that within N weeks every AMP user is on the new version. The thing that we can play with is N.

Would anyone here volunteer to write down the trade-offs and proposals for discussion in a design review or dedicated meeting?

[nainar]

@cramforce happy to take a crack at exploring all the options highlighted above.

[choumx]

Running a full QA cycle every week is probably a tall order for any site. Maybe we can keep our release cadence but simply offer cdn.ampproject.org/biweekly/v0.js that's updated every other week.

One technique that can work for AliExpress today is to replace unversioned AMP URLs with versioned URLs. This breaks AMP validation but m.aliexpress.com is already (intentionally) invalid.

I.e.

<!-- Unversioned v0.js -->
<script async src="https://cdn.ampproject.org/v0.js"></script>
<!-- Versioned v0.js -->
<script async src="https://cdn.ampproject.org/rtv/011903141753530/v0.js"></script>

<!-- Unversioned extensions. -->
<script async custom-element="amp-list" 
    src="https://cdn.ampproject.org/v0/amp-list-0.1.js"></script>
<!-- Versioned extensions. -->
<script async custom-element="amp-list" 
    src="https://cdn.ampproject.org/rtv/011903141753530/v0/amp-list-0.1.js"></script>

Here the RTV is 011903141753530 which corresponds to 01 (production experiments) + release number 1903141753530. This way, you can control the rollout timing of new versions of AMP on your site (as well as rollback if things go wrong).

One important risk is that critical/security bug fixes will require manual work to reach users, so I'd recommend (1) keeping your version as recent as possible and (2) monitoring GitHub for reported P0 bugs.

[cramforce]

I strongly prefer a mode where we'd start supporting (as in security fixes)
more past versions. I like the spirit of the
cdn.ampproject.org/biweekly/v0.js
We probably should not hard-code the actual cadence in the URL.

On Thu, Mar 21, 2019 at 8:31 AM William Chou [e-mail]
wrote:

Running a full QA cycle every week is probably a tall order for any site.
Maybe we can keep our release cadence but simply offer
cdn.ampproject.org/biweekly/v0.js that's updated every other week.

One technique that can work for AliExpress today is to replace unversioned
AMP URLs with versioned URLs. This breaks AMP validation but
m.aliexpress.com is already (intentionally) invalid.

I.e.

Here the RTV is 011903141753530 which corresponds to 01 (production
experiments) + release number 1903141753530
https://github.com/ampproject/amphtml/releases/tag/1903141753530. This
way, you can control the rollout timing of new versions of AMP on your site
(as well as rollback if things go wrong).

One important risk is that critical/security bug fixes will require manual
work to reach users, so I'd recommend (1) keeping your version as recent as
possible and (2) monitoring GitHub for reported P0 bugs
https://github.com/ampproject/amphtml/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22P0%3A+Drop+Everything%22+label%3A%22Type%3A+Bug%22+
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/20903#issuecomment-475278007,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT_cSt4jvIZJrBVphCUxSsSsRARS7ks5vY6W3gaJpZM4a-5T0
.

[aghassemi]

There are 3 requirements to consider here:
1- Increased "Dev Channel" period for testing.
2- Ability to have control over the version for a short & specific period of time (eg. during expected high traffic sale promotions) regardless of AMP's release schedule.
3- Ability for publisher to revert back a version in case of P0s before AMP has an opportunity to patch.

My proposal is allowing version pinning of RC and Prod to any "recent" version (e.g. previous 6 weeks releases). If a pinned version falls outside of the period, we warn and use latest.

<script async src="https://cdn.ampproject.org/v0.js?rc=1234&prod=5678"></script>

we could also provide aliases for an easier configuration of "Increased Dev Channel" use-case while maintaining 2 and 3:
?rc=this-month: first version cut of current calendar month
?prod=last-month: first version cut of last calendar month

@choumx AliExpress is valid AMP, just not the homepage.

[alankent]

One of the things Magento (open source e-commerce platform) has been trying to encourage is site test automation to be included in the deployment pipeline. I will say up front that most e-commerce platforms have from average to weak (to no) support for release test automation. But the more customized a site is, and the larger the merchant is, test automation is definitely on the rise.

If you believe sites should be tested before deployment, then auto-upgrading AMP code is an interesting one. Parts of the site are changing without going through the normal test pipeline. NodeJS npm/PHP Composer/etc purposely have a lock file to guarantee the version of the code running to help with diagnosing issues. Websites are a bit more interesting with the web due to various caches out there - atomic deployments are hard without a unique ID in the URL (timestamp, version number, MD5 checksum, or similar). So even with test automation included in a deployment pipeline, there can be issues with different CSS, JavaScript libraries, and so on in different caches. That is why never changing the content referenced by a URL can be helpful - websites are guaranteed never to pick up incompatible files.

The current AMP model is more like what web browsers have moved to. There are well defined definitions of how a browser is supposed to behave with lots of tests. That makes it safer to auto-upgrade browsers without even asking users. There is a clear contract between the browser and the page that does not change.

If AMP thinks it can control the interface between developers and AMP tightly, then the current auto-upgrade mode works. I must admit however if I had a larger e-commerce site, I would be worried that the production code at any point in time may not have gone through my test automation framework.

If you want the best of both worlds (give sites the peace of mind so they can test every change to the site before it goes live), then you could have URLs of the form /v2, /v3 etc where the contents can change (the AMP team can auto-upgrade your site), plus /v2.343 /v3.431 where the second number is some kind of build number (or version number). In this latter mode, once published, the content of a URL never changes. A site can then pick the new version they want to go with, test against it, deploy ti etc. and know that production code will not change until the next deployment they decide to do.

[danielrozenberg]

This has been formalized in #25578 and for the most part is now implemented. Closing this in favour of finalizing this in #25578