This does work for this one nightly but technically non-zero could also happen on the first position in the day or month.

I have just pushed ethereum/solc-bin#103 and we might actually have some nightlies like that in there.

Hm? This regex checks zeroes for months/days.

Ah you mean or. Yes, you're correct, need to improve it for that.

Could you run this on old nightlies? If there is no such instance, I think keeping this simple is better.

Bad news. We have several 0.3.6 nightlies that need this:

I have also detected another variant that triggers a crash:

The 0.3.4-0 case is partially handled, for 0.1.3-0 and 0.3.5-0. For both it was understood that the commit hash was set to 0.

However based on your comment it seems that happened for nightlies only? Can you check 0.1.3 and 0.3.4 what they output?

@cameel you may have missed these follow up questions

Oh sorry, I was sure I answered everything here. Apparently missed your question about releases.

Releases obviously do not have this problem because they do not include a date. You can check that on the list I prepared in the past when I was rebuilding binaries: ethereum/solc-bin#64 (comment)

The ([0-9]+)\.0?([1-9])\.0?([1-9])(.*) does not look quite right to me. Or am I missing something?

It looks to me like it would not accept two-digit month and day values that don't start with 0. Like 12 or 27. The test does seem to parse 2016.08.27 correctly though. Why?

• Is it because it pulls the final 7 into the .* part?
• Will it accept the 12 in 0.4.8-nightly.2016.12.16+commit.af8bc1c9.Emscripten.clang?

I think you can fix it by doing this instead:

const nightlyParsed = version.match(/^([0-9]+\.[0-9]+\.[0-9]+)-nightly\.([0-9]+)\.0?([1-9]|1[012])\.0?(3[01]+|[12]?[0-9])(.*)$/);

So the one and two-digits days and months (excluding leading zeroes) are included.

@r0qs Do you want to take over reviewing this?

@cameel I took a look in this PR, and my suggestion actually does not work for cases like: 2018.2.32, which would wrongly match: 2018, 2, and 3 instead of 32. Although 32 is not a valid day, the idea here is not to validate the date but only to match broken versions that contain the leading zeros. If a match does not happen, it will just return the version, assuming it is semver compatible.

So I changed @axic regex slightly to support cases like: 2016.12.06. Thus covering all the leading zero possible combinations for days and months: yyyy.0m.0d, yyyy.mm.0d, yyyy.0m.dd. Any version with a date that does not match the regex will be returned as it is.