Amphtml: Release badge should display the production release version

[estherkim]

The releases badge on amphtml's README displays the version at the very top of https://github.com/ampproject/amphtml/releases, which can be the canary release.

We should make sure that the release version displayed is always the production release.

[rcebulko]

Context:

Badges are rendered via Shields.io. Some are "pre-rolled", provided by the services themselves, such as the Travis build status badge or the various GitHub badges (PRs, contributors, the release version); these are handy, but have almost no customization, as is the case with the release badge including pre-releases. Others use the custom Shields.io endpoint API, where the URL for the badge image contains an endpoint URL (all project metrics badges). Shields.io hits this endpoint, and renders a custom badge based on the response. The response is a JSON object like below:

{
    "color": "green",
    "label": "Absolute Coverage",
    "message": "79.9%",
    "schemaVersion": 1
}

Because it has this specific form, existing server endpoints which may serve release info (like those in the GitHub API and elsewhere in our systems) can't be easily re-purposed to provide the endpoint for Shields.io. A new server endpoint needs to be created to serve the above data structure for the most recent release, meaning it will need to periodically fetch the latest true release from the GitHub API.

One option: the release-tagging bot should have the latest release number already available to it, and will be running a server anyway. Adding an endpoint here could be as simple as adding an extra node server endpoint.

Another option: the project metrics service serves all of the configs for each of the metrics badges, so one additional endpoint would be very minimal effort. The metrics app already maintains a table of (true) releases, so serving data for the latest one would be straightforward. The downside of this is, the release number isn't really a project metric, and it seems that might be a bit of scope creep, mixing concerns. That said, the simplicity of adding it there has its advantages.

The third option is an extremely simple ~10 line server with the exclusive purpose of serving the latest GitHub release number.

Any thoughts @estherkim @rsimha @danielrozenberg ?

[estherkim]

Interesting options! You know, I can't imagine us being the only repo using shields.io that has this problem. Have you tried looking at shields.io's GitHub issues?

Another idea is to look at how they're getting the version number to see if they're including isPrerelease as a query param.

[estherkim]

Aaand oops, I just noticed that the release number on our README.md is actually correct, it's only when you click on it that it shows the prerelease version first, which is misleading. Is there a way to always point to the latest published release?

[danielrozenberg]

Is there a way to always point to the latest published release?

https://github.com/ampproject/amphtml/releases/latest

[rcebulko]

Looks like we just need to change that one link in the readme! I'll throw a quick PR together