Impact of six month releases (original) (raw)

Mario Torre neugens.limasoftware at gmail.com
Fri Nov 3 10:17:48 UTC 2017

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.

More information about the jdk-dev mailing list