Tagging proposal for JDK GA releases

Kevin Rushforth kevin.rushforth at oracle.com
Thu Oct 4 11:52:01 UTC 2018 

I sent this before I read the good suggestion to not hijack this thread 
with a discussion of tagging builds, so I'll stop after this reply.

I should note that the suggestion to make the tagging changeset the 
parent of the changeset being tagged (with the attendant merge 
changeset) would be a departure from current practice, so could be 
considered in the future, but would need to be discussed further and 
done carefully.

-- Kevin


On 10/4/2018 4:45 AM, Kevin Rushforth wrote:
>
>> I didn't mean that the tag is on a Merge changeset,
>> I didn't know that rule.
>
> There is no such rule (and if there is, it would be wrong).
>
>> 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.
>
> This seems like a good idea, even if it does generate an extra merge 
> changeset.
>
> -- Kevin
>
>
> On 10/4/2018 2:09 AM, Lindenmaier, Goetz wrote:
>> Hi Jesper,
>>
>> I didn't mean that the tag is on a Merge changeset,
>> I didn't know that rule.
>>
>> 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.
>>
>> 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
>>>>>
>

More information about the jdk-dev mailing list