Solidity: Fix solc-bin upload script and rename 0.5.14 to full commit hash.

[ekpyron]

The commit hash for 0.5.14 is 01f1aaa4 - however, in solc-bin the file is uploaded as
https://github.com/ethereum/solc-bin/blob/gh-pages/bin/soljson-v0.5.14%2Bcommit.1f1aaa4.js
So with the leading 0 missing.

I think we should fix our upload script to include leading zeros and rename the release in solc-bin (while updating the commit lists).

Otherwise if I look at the release in solc-bin, I assume the commit hash is 1f1aaa4 and if I want to fetch it in the repo I get error: pathspec '1f1aaa4' did not match any file(s) known to git.

[ekpyron]

This is also the case for

• 0.4.13
• 0.1.3
• 0.1.2
• 0.1.1

For the last two I can't find a corrected commit hash, but for 0.4.13 and 0.1.3 it's also just a missing zero.
I'll fix 0.5.14, 0.4.13 and 0.1.3 in solc-bin, but we still have to fix our upload script - the issue can be expected to happen once in every 16 releases...

[ekpyron]

Wait a second... https://github.com/ethereum/solidity/pull/1074 explicitly changed the upload script to remove those leading zeroes... and there's a comment in the script about semver compatibility... so I think I'm not touching this for now, until this is clarified.

[chriseth]

The filename is not formed from the commit hash, it is formed from the version string. The version string cannot have leading zeros after the + (a semver restriction) and thus it is created by taking the commit hash and removing any leading zeros.

[Marenz]

But isn't commit. the "leading" part in this case? Or is this restriction true for any substring..number after the +?

[Marenz]

Which definition of SemVer are we using? This one here even has a leading 0 after the + as example.. https://semver.org/#spec-item-10

[chriseth]

The string is still split up into components separated by ..

You are right, @Marenz , the restriction only applies to the "prerelease" part, not the "build info" part. This is why the version is currently reported as 0.6.3-develop.2020.1.28+commit.c8994d9e.Linux.g++ instead of 0.6.3-develop.2020.01.28+commit.c8994d9e.Linux.g++ (the leading zero in the month is removed). So maybe the stripping of the zero was just not exact enough.

[Marenz]

so this sounds like we can revert the change in #1074 for the commit hash.. checking the script further, this is only used for the metadata component. :+1:

[ekpyron]

So https://github.com/ethereum/solidity/pull/1074#discussion_r371322848 was not intentional after all :-)? The version string (as reported by "solc --version") actually does contain the leading zero in the commit hash, only the upload script removes it from both the date and the commit hash. So I agree with @Marenz in that in particular the line here https://github.com/ethereum/solidity/pull/1074/files#r367942424 should be reverted, resp. removed (while the leading zero should still be removed from the date).

[chriseth]

The commit contains two changes: Changing the date format from -utc +%Y.%m.%d to -utc +%Y.%-m.%-d (adding two -), and removing the leading zero in the commit hash. The first change is needed, the second is not.

[ekpyron]

The respective line that strips the leading zeroes from the commit hash is removed in https://github.com/ethereum/solidity/pull/8227 .
But we still need to decide how to deal with the old releases affected by this. We might want to keep the versions with the zeroes stripped in solc-bin, do we? If so we could add a symlink to the same release with the zero and have the lists point to the ones with zeros - but that would probably involve making an exception for these cases in the update script.
Or we could just ignore this for old releases...

[chriseth]

Maybe we just ignore them for now...

[ekpyron]

The main problem in ignoring them is that I have added them with the leading zeroes to the wasm directory... "them" being 0.4.13 alone actually... so that might be confusing...

[ekpyron]

I'm adding the "to discuss" label to this, so that we can decide it's immediate fate.