Use JDK-Head version number instead of 'jdk'

[M-Davies]

• Renames JDK-Next binaries to include the major version number
• I.e.OpenJDK-jdk_x64_windows_hotspot_2020-03-27-03-31.zip to OpenJDK15U-jdk_x64_windows_hotspot_2020-03-27-03-31.zip
• Includes various documentation and script updates to allow this to function

Ref: #1016 (Doesn't close it)
Signed-off-by: Morgan Davies [email protected]

[M-Davies]

OFF SIGHT REQUIREMENTS FOR THIS

• Update names of downstream jdk-next jobs to be jdk15u-blahblahblah https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk/
• Update job regenerator to pipeline_jobs_generator_jdk15u https://ci.adoptopenjdk.net/job/build-scripts/job/utils/job/pipeline_jobs_generator_jdk/

[karianna]

Apologies but I landed another doc PR so the release notes have a conflict

[M-Davies]

At this point, all I'm doing is renaming the binary to OpenJDK15u blah blah. Im not touching the actual javaVersion set by the pipeline

[douph1]

as discussed here :
#1574

I don't think hard coded JDK-Latest to "15" like already here getJavaVersionNumber() or "15U" a second time is a good idea (maintainability point of view )

If you intended only to fix adoptium/installer#211 here I think I can better handle it in installer script because upstream job always pass the major version number.
So I can search for OpenJDK (without major number) and use it as JDK-Latest = PRODUCT_MAJOR_VERSION and not hardcoded any number either on my side or your side.

[M-Davies]

@douph1 Yes this was more to fix recent installer failures but if you think you can handle it on the installer side then I would prefer to do that. In addition, 1574 seems to be a better solution to this in the end than this since it avoids extra documentation when JDK-Head gets bumped.