Rename version from RTV to readable string about error-tracker

[danielrozenberg]

To add some context - in free conversation we often talk about versions using their last 3 digits, which will become pretty useless after ampproject/amphtml#27848, so having another shorthand can help a lot!

[danielrozenberg]

1. With a letter, an un-informed reader could easily misread it as a git commit SHA

We can use α/β/γ/δ instead of a/b/c/d to address this concern 😅😅😅😅

[estherkim]

+1 Ryan's points. I'd like to see how the 000, 001, 002 syntax works out.

[rcebulko]

The most useful places for these strings to be used would be user- and developer-facing places:

• release infrastructure UIs
• error reporting UIs
• release-tracking issues
• GitHub releases
• "Powered by AMP ⚡ HTML - Version XXXXXXXXXX" log to console

Places that programatically consume/use the RTV should not be altered; this should be a purely cosmetic improvement

• https://cdn.ampproject.org/rtv/metadata
• version in AMP_CONFIG
• most logging during build/release process

In some cases, the string will be useful while the raw RTV should still be included to allow for exact matching, such as between the console logged version and the RTVs in /rtv/metadata. GitHub releases and release-tracking issues should still include the raw RTV somewhere in the body, but the title could benefit from the readable string.

[estherkim]

I agree with the intent, but I'm wary of making changes because the human readable name will change a lot when it goes through different channels.

Since we're already changing the format with @danielrozenberg's cherry pick I2I, can we let that breathe for a little before changing the name? I want to be careful not to cause extra confusion by moving too fast.

[rcebulko]

I agree with the intent, but I'm wary of making changes because the human readable name will change a lot when it goes through different channels.

Can you clarify what you mean by this?

Since we're already changing the format with @danielrozenberg's cherry pick I2I, can we let that breathe for a little before changing the name? I want to be careful not to cause extra confusion by moving too fast.

This has been planned for a couple months to change in error reporting by the end of April. As for the rest (ie. releases, issues, logging) since it's adding the string and the RTV will still be there, I don't see it causing much confusion, and could actually sync well with the cherry-pick changes.

@danielrozenberg WDYT re: confusion around this + cherry-pick changes?

[danielrozenberg]

I don't see a problem having a different format in the error reporting tool, as long as the full, standard version number is also available and easily reachable for display (e.g., for searching in page)

[danielrozenberg]

Last-minute opinion, how about the version with no cherry picks end with a, with 1 → b, 2 → c, ..., 26 → aa, 27 → ab, ...

This way most versions will have a fingerprint such as (1234a), and cherry-picked releases will be (1234b), (1234c)...

This could be easier to say out loud ("one two three for aye" and "one two three for bee" instead off "one two three four" and "one two three for plus one") and removes any ambiguity whether one refers to the base of a release branch, or to the specific (non-cherry-picked) release

Update: neat easter egg, the version number for cherry-pick 999 would be all!

function x(n) {
  const lsb = String.fromCharCode(97 + (n % 26));
  if (n / 26 >= 1.0) {
    return `${x(Math.floor(n / 26) - 1)}${lsb}`;
  }
  return lsb;
}

// x(999) -> 'all'

[rcebulko]

Hmm that's a really interesting idea. I do like it because, as you say, it's clearer to vocally say (plus that is an awesome easter egg).

I see two disadvantages:

1. With a letter, an un-informed reader could easily misread it as a git commit SHA
2. With the +1 syntax, it seems a bit clearer that it's an extension/cherry-pick

I don't feel too strongly either way; very curious what @estherkim and @rsimha think about each of these options. Will defer to the thread/whichever option gets 2/3

[jridgewell]

I kinda like the +1 syntax.

[rsimha]

+1 to the +1 syntax.

[erwinmombay]

also prefer the +1 syntax 🕺

[rcebulko]

Part of #112

Implemented in #127