sean.coffey at oracle.com
Wed Feb 27 08:41:47 UTC 2019
JBS records with the 'hgupdate-sync' label can normally be ignored for
On 26/02/2019 22:07, Andrew Hughes wrote:
> On Tue, 26 Feb 2019 at 19:22, Gil Tene <gil at azul.com> wrote:
>> Given the proposed process for the 8u quarterly releases going forward, I think that 8u212 would we the proper
>> tag for the actual April release under such a process. [See separate discussion under "Numbering of updates in
>> future 8u quarterly releases" (e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008564.html)
>> where we seem to have a quiet consensus that using the 8uXX2 numbers is the least-bad choice for now]
>> I guess we could have two tags (8u211 and 8u212) to distinguish the presumably security-related stuff from other
>> things as has been done traditionally, and just assume that everything tagged 8u211 is also included in the 8u212
>> Or just one for both, which should probably be 8u212.
>> Which will be more confusing?
>>> On Feb 26, 2019, at 10:48 AM, Andrew Haley <aph at redhat.com> wrote:
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>> <openjdk8u211 tag.eml>
>>> Begin forwarded message:
>>> From: "Hohensee, Paul" <hohensee at amazon.com>
>>> Subject: openjdk8u211 tag
>>> Date: February 26, 2019 at 10:17:51 AM PST
>>> To: Andrew Haley <aph at redhat.com>
>>> Noticed it replacing the openjdk8u tag. I thought there wasn’t going to be an OpenJDK 8u211, only a u212?
> I guess this is my fault, because I'm still used to only really
> thinking about the odd releases. We've
> never shipped even releases because they simply weren't available to
> do so until after embargo.
> Also, I believe the position from Oracle was that "PSU" releases
> should only be used if a specific
> bug fix was needed early.
> I don't think it really makes a great difference. The perception I had
> that Oracle were only using 8u211
> in the referenced e-mail has since been proved wrong;
> shows 8u211, 8u212, 8u221 and 8u222 all in use (goodness knows why
> they need backports to all of those!)
More information about the jdk8u-dev