Tagging proposal for JDK GA releases
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Thu Oct 4 09:44:19 UTC 2018
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/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