I'm good with the time frame. I have a broad concern with the definition of core module, since I've never seen a list of them.
- Jason On Thu, Jul 5, 2018, at 11:11 AM, Daniel Klco wrote: > 1 Year following the LTS is the proposal, not married to that particular > timeframe, but there should be some time to make updates, do regression > tests, etc. > > I don't think running on intermittent issues should be an issue, nor should > having non-core bundles depend on an intermittent release, I'm specifically > referring to the version in the parent POM and used for the core bundles. > > On Thu, Jul 5, 2018 at 10:58 AM Jason E Bailey <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > >
