OpenJDK SRU exception

[Steve Langasek]

On Fri, Mar 23, 2018 at 09:43:40PM -0700, Steve Langasek wrote:
> On Fri, Feb 2, 2018 at 11:58 AM, Tiago Daitx <tiago.daitx at canonical.com> wrote:
> > On behalf of the Ubuntu Foundations Team, I am requesting an SRU
> > exception for OpenJDK. Our plan is to release OpenJDK 10 as the
> > default JRE/JDK [1] for Bionic, and then move the default JRE/JDK in
> > main to OpenJDK 11 in September/October 2018 as an SRU.

> > = Proposed Plan =
> > Bionic will be released with OpenJDK 10 as the default JRE/JDK and
> > OpenJDK 11 will replace it once it reaches GA.

> > OpenJDK 8 will be moved to universe and remain available there for
> > 18.04, to provide migration time for packages that can't be build with
> > OpenJDK 10 or 11.

> > OpenJDK 8 will remain in main in 16.04 LTS (which reaches EOL in April 2021).

> Not mentioned in this description is that we should migrate ASAP to OpenJDK9
> by default, to ease the transition to OpenJDK10 between now and release.

> (Not mentioned because at the time you first wrote, this wasn't expected to
> miss feature freeze.)

> > If we are going to switch to OpenJDK 11 in bionic once released, we
> > want to avoid OpenJDK 8 as the default JRE/JDK in Bionic at release
> > time because any additional interface delta that exists between 8 and
> > 11 not only exposes the archive to breakage, it also exposes external
> > consumers of the JDK to breakage.  In comparison, the interface delta
> > between OpenJDK 10 and OpenJDK 11 is expected to be fairly small,
> > especially in comparison with the delta between OpenJDK 8 and OpenJDK
> > 9 that we already know is large.  We should therefore release with
> > OpenJDK 10 as the default JDK in 18.04, transitioning to OpenJDK 11
> > when it is released.

> I agree with this rationale and approve this SRU exception for OpenJDK 11 in
> Ubuntu 18.04 LTS.

One further outstanding question is how to name these packages in order to
avoid leaving binary packages in main at release time with no security
support and no automated upgrade path.

My suggestion is to use the same source and binary package names for both
openjdk-10 (at release time) and openjdk-11 (once SRUed) in bionic, so that
the upgrade just happens normally as part of security updates and there are
no concerns of users who upgraded to 18.04 early being islanded on a
no-longer-supported openjdk-10 package.

One way to do this would be to simply name the openjdk-10 package
"openjdk-11", with a 10.x version number.  This would signal to users that
openjdk-11 is coming, making it less of a surprise.

You could also call it openjdk-10, but it's less obvious to have an
openjdk-10 version 11, IMHO.

You could even do something like "openjdk-lts", but that also has downsides
of confusion with the upstream meaning of LTS.


Alternative approaches, which have been considered but that I think are
worse than the above:

 - Keep openjdk-10 only in the -proposed pocket until after release, then
   publish it to -updates.  This would mean that either there is no openjdk
   in the release pocket at bionic release, so 18.04 is not self-buildable;
   or there would be some other version of openjdk left in the release which
   is *also* going to go EOL, and is therefore also going to mislead users.

 - Publish openjdk-10 in main in the bionic release pocket, but use metadata
   in the archive to mark it only supported in September.  This doesn't help
   the majority of users who never run ubuntu-supported-status or look at
   the field in their Packages files.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20180323/1cc8c02f/attachment-0001.sig>