🏗 Generate a consistent version number when building/disting#16631
🏗 Generate a consistent version number when building/disting#16631erwinmombay merged 2 commits intoampproject:masterfrom
Conversation
|
I like it. This maintains the property that later releases have higher "timestamps", right? |
|
@cramforce other than the fact that this PoC doesn't work (gotta work out some async kinks,) the answer is yes-modulo-1-sec. The module-1-sec is extremely unlikely in how we create releases and release branches. e.g., if we this is the tree: The release created from The only case where the release number won't be higher is if, say, we were to cherry pick In this case Of course right now if you were to run As for the "modulo-1-sec" issue, if someone were to cherry-pick a commit onto a release branch at the exact same second that someone else committed a commit to another release branch, there's no guarantee of order between the two, e.g.: In this case |
34d9485 to
cc44e6d
Compare
Codecov Report
@@ Coverage Diff @@
## master #16631 +/- ##
==========================================
+ Coverage 77.82% 77.83% +0.01%
==========================================
Files 562 562
Lines 41170 41170
==========================================
+ Hits 32039 32046 +7
+ Misses 9131 9124 -7
Continue to review full report at Codecov.
|
|
Using commit time should work for cherry-picks across multiple release branches and custom amphtml forks. Schedule for next design review? |
|
From design review discussion: @cramforce wants to change the version numbers to be human readable, instead of seconds-since-epoch - e.g., As we're making this change now, in the year 2018, version numbers will start with /cc commentators in the design review meeting: @cramforce @jridgewell @erwinmombay @rsimha @choumx (apologies if I forgot someone) |
cc44e6d to
ccc558a
Compare
|
PTAL |
c254306 to
7030137
Compare
|
Rebased on master, PTAL |
|
Delayed "yay!" :) |
…ect#16631) * Generate a consistent version number when building/disting * :%s/{int}/{number}
@choumx and I discussed the idea of changing the way we generate version numbers from relying on the timestamp of when the user hit enter on
gulp [build|dist]to have a consistent version number, so that runninggulp [build|dist]on the exact same commit would create the exact same output.Our current version numbers are 13 digits long, where the 13 digits represent a timestamp in milliseconds.
My proposal is this formula:
For the first 10 digits we continue to use the timestamp, which we take from the commit time (not author time.) Git only stores the seconds, not milliseconds, so we cannot rely on a 13 digits timestamp as the version number.
For the last 3 digits we take the short commit hash (e.g.,
a2a6e4ad5) and convert it back into a number, then modulo 1,000 to get 3 digits, then left-pad with 0's. This is to avoid the (highly unlikely) case in which two commits were committed at the exact same second.If there are any uncommitted files in the working directory (staged or otherwise,) the last 3 digits will be replaced with 000, to indicate that.
This PR is a proof-of-concept and a place to start a discussion around this. What do you all think?