Naming convention for build downloads is YYYYDDMM not YYYYMMDD

[lumpfish]

The date part of the JDK download binaries is in YYYYDDMM format rather that the more usual YYYYMMDD.

So OpenJDK8-OPENJ9_x64_Linux_20180203.tar.gz is the build of the 2nd March and OpenJDK8-OPENJ9_x64_Linux_20181203.tar.gz is the build of the 12th March.

Is that intentional? If so, what was the reasoning behind it?

[karianna]

Not intentional - I'd actually prefer a clearer DDMMYYYY format although YYYYMMDD is also acceptable.

[io7m]

YYYYMMDD has the advantage of being lexicographically ordered. Sort strings of that format in ascending lexicographical order and you also get them in ascending chronological order for free.

[karianna]

Fair point

[cstroe]

Looks like this should be fixed by #450 ?

[keithc-ca]

This was fixed earlier, but the build flow has changed dramatically and I'm not sure where the source of the YYYYDDMM pattern is (#450 is targeted to a branch that isn't (yet?) being used as far as I can tell).

[sophia-guo]

This should only happen to SDK OpenJDK8_aarch64_Linux_***, as build job openjdk8_build_aarch64_linux is configured differently. https://ci.adoptopenjdk.net/job/openjdk8_build_aarch64_linux/configure . That is saying this build doesn't use build story from openjdk-build (though I don't know why). I've updated the execute shell to

readonly TIMESTAMP="$(date +'%Y%m%d%H%M')"
# hardcoded major version and platform (architecture and os)

Which should solve this problem.
Ideally should set job parameter TIMESTAMP.

[sophia-guo]

Today's aarch64 jdk8:OpenJDK8_aarch64_Linux_201808301146.tar.gz. Others look also good, good to close this for now. ( didn't realize I do not have permission, @karianna could you close it?)