Tagging proposal for JDK GA releases

[Lindenmaier, Goetz]

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