Just a note, Java 11 is coming out in Sept. of this year. Are you thinking of switching the parent pom over a year after the LTS or is that a typo.
Also we should support the running of Sling on an intermittent release. - Jason On Thu, Jul 5, 2018, at 8:44 AM, Daniel Klco wrote: > Another thing to keep in mind is that Java is moving to biannual releases > and Long Term Support vs non-LTS with Java 9+. We'll need a strategy of how > to handle the new release schedule as it may not even make sense to support > the non-LTS versions. > > What if we had a policy like: > > - Only use LTS Java Versions for the core codebase > - Make the latest LTS Java version the codebase standard 1 year > following the release of that LTS version > - Support development on non-LTS versions in individual bundles > > This would have us: > > - Upgrade to Java 8 for ongoing development (since Java 9 is not LTS) > - Upgrade to Java 11 in September 2019 > - Upgrade to Java 17 (the next LTS) on September 2022 > > WDYT? > > On Thu, Jul 5, 2018 at 7:43 AM Eugen Stan <[email protected]> wrote: > > > Hi, > > > > There are good arguments to both sides. If it comes to a vote, I'm all > > in for moving baseline to Java 8 in one swoop. It makes things simpler. > > > > There are great many API improvements that we could benefit from: > > streams, lamdas, date time API, collections improvements, Optional > > updates, etc. > > > > Regards, > > > > > > On 05.07.2018 11:43, Bertrand Delacretaz wrote: > > > Hi Jason, > > > > > > On Wed, Jul 4, 2018 at 9:27 PM Jason E Bailey <[email protected]> wrote: > > >> ...1. I would not consider using or not using java 8's lambda's a > > "programming comfort" > > >> the paradigms introduced with Java 8 such as lambda's and streams > > fundamentally > > >> change how the source is written and in my experience results in > > concise, easier > > >> to understand code... > > > I agree! > > > > > > But if you're making a minor change to an existing core bundle it > > > might be better to stick to the current Java version that's used for > > > that bundle, instead of changing just because a few lines look nicer. > > > > > > I guess it's a question of balance between what "minor changes" and > > > "better code" are. > > > > > > The most recent discussion that I found about that is this one > > > > > > > > https://lists.apache.org/thread.html/0bdd59ec761ec07a3fc35144cf9fa9b318496dbc78958127515799b8@%3Cdev.sling.apache.org%3E > > > > > > where we seemed to have consensus about moving individual bundles to > > > Java 8 (as opposed to making that the default, for now) if that brings > > > tangible benefits. > > > > > > At this point I see two options: > > > > > > a) Continue moving individual bundles as needed, and IMHO it's good to > > > do a 72-hours [LAZY] vote before changing core bundles like engine, > > > API etc. > > > > > > b) Revisit that discussion and make Java 8 the default in the parent pom > > > > > > I don't have strong opinions myself, I just want such decisions to be > > > made explicitly by this PMC and community. > > > > > > -Bertrand > > > > > >
