Tagging proposal for JDK GA releases (original) (raw)

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/spectrapredefineclassclassloaders/Launcher.java times out in JDK12 CI | * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTEPRINTF | * 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/spectrapredefineclassclassloaders/Launcher.java times out in JDK12 CI |  | *  |  8204294: [REDO] - JVMFlag::printError missing ATTRIBUTEPRINTF |  | *  | 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-updates-dev mailing list