Tagging proposal for JDK GA releases

[Kevin Rushforth]

> Sorry, my mistake. We are not supposed to tag merge changesets.
> I have re-tagged jdk-12+14 to a non-merge change.

I don't understand this comment. If the merge changeset is what you 
built from then why wouldn't you tag that? If you don't, then you won't 
be tagging the sources as they were built.

-- Kevin


On 10/4/2018 1:47 AM, jesper.wilhelmsson at oracle.com wrote:
> 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
>>>