Tagging proposal for JDK GA releases

[Lindenmaier, Goetz]

Hi, 

I also think this would make things more clear.

I want to propose another point I stumbled about lately.

You all know that if I do hg clone -r jdk-10.0.2-ga 
I get all the changes, but not the change that tags the version.
I often check for the hash of the change tagging the release
and clone that. Then I have a repo whose last change is the ga tag.

Unfortunately recently, the tag comes later and is not directly
applied to the change it wants to tag, but a few changes later. E.g.,
tag 12+14 is applied on top of "8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError"
while it tags "Merge 8897e41b327c":
http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1

* Added tag jdk-12+14 for changeset 8897e41b327c
|
* 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError
|
* 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative
|
* 8211150: G1 Full GC not purging code root memory and hence causing memory leak
|
* 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false
|
* 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI
|
* 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF
|
* 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= 
|
* Merge  8897e41b327c  jdk-12+14 

The following would be more convenient: 

*Merge
| \
|  * Added tag jdk-12+14 for changeset 8897e41b327c
|  |
*  |  8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError
|  |
*  |  8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative
|  |
*  | 8211150: G1 Full GC not purging code root memory and hence causing memory leak
|  |
*  |  8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false
|  |
*  |  8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI
|  |
*  |  8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF
|  |
*  | 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= 
| /
* Merge  8897e41b327c  jdk-12+14

Which easily can be achieved by doing hg update -r 8897e41b327c (the merge change) 
before doing hg tag -f.

Best regards,
 Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Hohensee, Paul
> Sent: Mittwoch, 3. Oktober 2018 17:25
> To: Seán Coffey <sean.coffey at oracle.com>; jdk-dev <jdk-
> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u-
> dev at openjdk.java.net
> Subject: Re: Tagging proposal for JDK GA releases
> 
> We at Amazon would find this useful.
> 
> Thanks,
> 
> Paul
> 
> On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Seán Coffey" <jdk-
> updates-dev-bounces at openjdk.java.net on behalf of
> sean.coffey at oracle.com> wrote:
> 
>     I'd like to propose an enhancement to the JDK build-tagging
>     convention to help users more easily identify JDK GA releases
>     via Mercurial tag names.
> 
>     The concept is quite simple and lets people identify snapshots
>     of GA releases in Mercurial history without having to know the
>     build number of the GA release.
> 
>     For example, to obtain JDK 10.0.2 GA sources today, one issues the
>     `hg update -r jdk-10.0.2+13` command. With the proposed
>     enhancement, `hg update -r jdk-10.0.2-ga` could have been used.
>     It's proposed that the new ga tag would be in addition to the regular
>     GA build number tag. It would be added to the relevant repository
>     once the GA milestone has been reached.
> 
>     This new convention would be used for future JDK releases and is
>     tracked via JDK-8180946[1]. If the changes are adopted, I can
>     look at retroactively adding labels for all feature JDK GA releases
>     since JDK 7 to the JDK feature-release main-line repository.
> 
>     To accommodate the new tag format, some simple jcheck edits
>     would be required. Test checks would also be added.
> 
>     Comments?
> 
>     regards,
>     Sean.
> 
>     [1] https://bugs.openjdk.java.net/browse/JDK-8180946
>