Rename version from RTV to readable string
rcebulko opened this issue · comments
Right now RTVs are used to reference release versions:
- in release tracking issues
- in error reporting dropdowns
- in the
consolemessage in AMP pages - in discussions about regressions
- in the release dashboard
In many of these contexts, a readable form of this version could be more useful for communication, understanding, and cross referencing between threads, errors, etc. I'm leaning towards a mapping like the following:
'052004030010070' --> '04-03 Nightly-Control (0010)'
'012004030010000' --> '04-03 Stable (0010)'
'012004030010001' --> '04-03 Stable (0010+1)'
'012004030010002' --> '04-03 Stable (0010+2)'
'022004030010070' --> '04-03 Control (0010)'
'002004172112280' --> '04-17 Experimental (2112)'
'032004172112280' --> '04-17 Beta (2112)'
'042004210608300' --> '04-21 Nightly (0608)'
These version strings
- sort chronologically by default
- indicate cherry-picks via
+1,+2, etc. - used the hour/minute digits for a "fingerprint" of an RTV
- are simple enough to remember and type without needing to copy-paste
These strings should be easier to remember, understand/parse, and communicate about. The fingerprints could act as a shorthand in discussions.
"We promoted Stable from 0010 to 2112, but 2112 was borked so we rolled back to 0010 until we could validate cherry-picking #1337 to 0010+1 fixed the issue. The bugfix #1337 is already in 0608"
I think some version of this stringification would improve clarity in most or all of the locations above. In some places (ex. release tracking issue), it would make sense to include both the stringified form and the raw RTV.
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!
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.
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.
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?
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)
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'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:
- With a letter, an un-informed reader could easily misread it as a git commit SHA
- With the
+1syntax, 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
- 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 😅😅😅😅
+1 Ryan's points. I'd like to see how the 000, 001, 002 syntax works out.
I kinda like the +1 syntax.
+1 to the +1 syntax.
also prefer the +1 syntax 🕺