Tagging proposal for JDK GA releases

[Jesper Wilhelmsson]

> 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz <goetz.lindenmaier at sap.com>:
> 
> Hi Jesper, 
> 
> I didn't mean that the tag is on a Merge changeset, 
> I didn't know that rule. 

It’s more a guideline than a rule I guess. But I’ve heard it can cause issues in some cases.

> What I mean is, in other words than in my mail below:
> I would like that the parent of the tag change is the 
> change to be tagged.
> I know this means that there will be a merge, but 
> it seems worth while.

Has it been done this way in the past? I’ve only been tagging promoted builds for a short while, I may be missing some step that was part of the process before.
/Jesper

> Best regards,
>  Goetz.
> 
>> -----Original Message-----
>> From: jesper.wilhelmsson at oracle.com <jesper.wilhelmsson at oracle.com>
>> Sent: Donnerstag, 4. Oktober 2018 10:48
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: Hohensee, Paul <hohensee at amazon.com>; 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
>> 
>> The proposal looks good to me.
>> 
>>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I also think this would make things more clear.
>>> 
>>> I want to propose another point I stumbled about lately.
>>> 
>> 
>> Sorry, my mistake. We are not supposed to tag merge changesets.
>> I have re-tagged jdk-12+14 to a non-merge change.
>> 
>> I would like to take the opportunity to highlight that the hg history would be
>> a lot easier to work with if everyone remembers to rebase their changes
>> before pushing. Then we would have a lot fewer merges in there.
>> /Jesper
>> 
>>> 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
>>>> 
>>> 
>