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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Oct 4 09:09:55 UTC 2018

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 > 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" > 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