Impact of six month releases

[Mario Torre]

We also need to consider that breakage is usually caused by the massive
feature count introduced in each release, with a faster release cycle we
have more chances to introduce features incrementally instead of the old
patch bomb style approach, lowering the risk of substantial breakage.

There will likely be a domino effect where all those projects will start
moving at the same time aligning with the release pace of the jdk.

That said, I think the quality outreach project and our downstream testing
will have a larger role to play in this scenario.

Cheers,
Mario
On Fri 3. Nov 2017 at 10:42, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 03/11/2017 00:21, Ryan Schmitt wrote:
> > I have similar concerns along these lines. For example, JDK9
> > introduced the "one plus three back" policy for cross
> > compilation, such that javac in JDK9 can now only target JDK6
> > and newer. Under the old release schedule, "one back plus
> > three" could easily cover a decade's worth of JDKs, but now
> > that window will shrink to approximately two years. There are
> > similar questions around JDK deprecations: how long do my
> > dependencies have to migrate to VarHandles and StackWalker?
> Moving to a feature release every 6 months will mean re-examining these
> policies, some will probably need to be changed to be based on time
> rather than "next release". The issue of APIs that are
> deprecated-for-removal is, at least in my view, the most important to
> decide on soon as it is impacts several areas with patches pending. Yes,
> policies for `javac --release N`, the version that jrtfs is compiled to
> is another, and there are several others.  Not clear if there is a
> "one-size-fits-all" policy, esp. when you get into the undocumented
> internal APIs and how aggressively we can remove/refactor internals when
> there are standard/supported APIs available.
>
> -Alan.
>