amphtml: 'src' attribute set to invalid in amp-mustache script

Versions should not be introduced and deprecated in the same release cycle for many reasons.

As @jamesshannon has kind of mentioned.

It is absolutely not OK to be notified of deprecation events solely via emails generated by GSC. I’m not sure if it was documented somewhere else and I perhaps missed it, but if there isn’t a deprecation timeline map available, we definitely need one.

I mention this again because our app converts 1000s of customers pages into AMP, and when they receive a “Warning - you are about to be penalized in search results” (paraphrased) email, they rightfully flood our customer support with messages that could have certainly been avoided.

Thank you for the update. I think it’s now been addressed that there was a screwup. Looking forward to improved standards moving forward.

Cheers

Hi.

Since yesterday I’m getting a lot of errors in search console and it’s referencing the URL to amp-mustache v0.2 version:

User-authored JavaScript found on page: The attribute 'src' in tag 'amp-mustache extension .js script' is set to an invalid value

The AMP validator in chrome is saying that everything is ok.

As part of the post-mortem action items, we’ve updated and clarified our versioning policy in #17370.

Moving forward, all extension version deprecations will follow a strict deprecations process including announcement on public channels, community discussion, and constrained timelines to deprecation/invalidation. For example:

A version must not be deprecated until a new version is released and stable for at least 1 month. A version must not be invalidated until it has been deprecated for at least 1 year.

amp-mustache’s version notes have also been updated with more details.

Please see the attached post mortem on this issue.

Post-Mortem-amp-mustache-0.2.pdf

Please publish an article about this, I’m being inundated with complaints by users experiencing this. We have an app that converts pages into AMP. We updated to 0.2 per the error. We need a link to send them saying this is Google’s fault. Help.

Oh. Another thing around this:

The version notes aren’t particularly helpful in for the purposes of deprecation.

• First, how relevant is the version notes for a particular library? It looks like version notes are only used for minor releases (and not patches). But functionality is regularly added to libraries via “patches”. Certainly it woudln’t be surprising if <svg> features were added and the bundle size was reduced without a major or minor version, and thus that wouldn’t typically get added to the Version Notes. If that’s the case, then what’s the point of having Version Notes at all? Maybe they should be deprecation notes?

• The bundle size comment was confusing. I assumed that that referred to something similar to the the 50kb CSS limit. The actual gzipped JS library size doesn’t seem relevant enough for this.

• Last but not least – if I have dozens or hundreds of AMP pages which I’m responsible for, the description (“Internal improvements may cause minor breaking changes”) doesn’t really help me migrate to v0.2. What should I be looking for? On which pages? I wouldn’t expect that a “minor breaking change” – especially to mustache templates – would be immediately visible. With amp-bind and other components, a lot of functionality is hidden under actions. Do I need to (manually) test every action on every page? How do I know that just because I’ve noticed one discrepancy there might not be others? The Deprecation Notes should describe exactly what might happen, and how that might occur. Should I look for unreplaced variables? Or text that’s suddenly backwards?

Please email me the URL you are testing (same username @google.com)

I really need some confidence that this is being fixed, or a timeline on when…

If we revert back to 0.1, will the warning still show? It says that a commit was pushed to remove the deprecation warning but other users seem to be still experiencing warnings.

Please advise ASAP.