Tagging proposal for JDK GA releases (original) (raw)
Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Oct 4 09:44:19 UTC 2018
- Previous message: Tagging proposal for JDK GA releases
- Next message: Tagging proposal for JDK GA releases
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi
I think before, when no-one committed to jdk/jdk because there were the hs/comp/gc etc repositories it happened by process. I.e., no changes were merged into the repo before the build was tagged.
I think all the jdk10 tags have the tagged change for parent. This is no more the case since jdk11.
Best regards, Goetz.
-----Original Message----- From: Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> Sent: Donnerstag, 4. Oktober 2018 11:38 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
> 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/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 >>>> >>> >
- Previous message: Tagging proposal for JDK GA releases
- Next message: Tagging proposal for JDK GA releases
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]