force date into a semver-compliant version

[jeremyd2019]

The version with year-month-day was not passing a semver.valid check, and thus causing tool-cache to not find a previously-cached version. They really should fail when trying to cache an "invalid" version, if they're going to fail to find it later.

[jeremyd2019]

I am testing this more in my fork now...

[jeremyd2019]

Note further complicating testing is that my self-hosted runner is running Windows 10 20H2 ARM64, which cannot run x64 binaries. So I'm having to use my fork branch that installs 32-bit msys2. But, this version format seems to make it happy:

  ##[debug]isExplicit: 0.0.20210704
  ##[debug]explicit? true
  ##[debug]checking cache: C:\runner\_work\_tool\msys2-installer\0.0.20210704\x86
  ##[debug]Found tool in cache msys2-installer 0.0.20210704 x86

as opposed to:

  ##[debug]isExplicit: 
  ##[debug]explicit? false
  ##[debug]isExplicit: 
  ##[debug]explicit? false
  ##[debug]evaluating 0 versions
  ##[debug]match not found
  ##[debug]Downloading https://github.com/jeremyd2019/msys2-installer/releases/download//2021-07-04-build32/msys2-base-i686-20210704.sfx.exe

[eine]

What's the problem with the follwing?

const version = `${inst_version.replace(/-/g, '.')}`

[lazka]

Using the last part only makes the version incompatible to all other versions according to semver.

[eine]

Thanks! I will add a comment about it!

[lazka]

good idea. (though I don't know if anything does any semver related version comparison here, but that's one advantage I could think of)

[jeremyd2019]

what I was thinking is that if msys2 ever wanted to use 'real' versions, version numbers up to 2021 (or even newer) would be considered 'older' than version 1.0.

I do think there is some semver comparison going on in the tool-cache too.