Agree, we don't gain much with moving to Java7. Thus I'd say that we keep Java6/CDI-1.0 and have the next major version bump (aka DeltaSpike-2.x) targeting Java8 and CDI-2.0. But of course keep a ds-1.x maintenance branch even after that for a while.
LieGrue, strub > On Thursday, 7 April 2016, 14:42, Gerhard Petracek <[email protected]> > wrote: > > as mentioned in the initial discussion i also don't see a real benefit for > us as a community (to drop the java 6 support at this point). > in the end ds targets ee6 + supports ee7 servers (including optional > features). > ee6 isn't bound to java 6 technically, however, e.g. some vendors require > it... > > regards, > gerhard > > > > > 2016-04-07 13:18 GMT+02:00 Rooda, William (John.) <[email protected]>: > >> Ford has an internal “shared farm” of servers that our applications can >> use. The shared farm is Websphere Application Server 8.0.0.x. This only >> has Java6 available. While some teams go out and spend the money to >> procure their own servers outside of the shared farm, this is prohibitively >> expensive without a powerful use case. >> >> >> >> Our Java applications won't have a server offering in our internal > shared >> farm for Java 7 until 4Q2016 or 1Q2017 at the earliest. We plan on >> developing almost all applications against Java6 until that time, and >> unfortunately we have to re-evaluate continuing to use at an enterprise >> level any open source software that no longer patches and supports Java6 >> due to the risk it introduces to our applications. We understand that this >> makes us an outlier in the community of DeltaSpike users. >> >> >> >> Thanks, >> >> >> >> ~john >> >> >> From: John D. Ament [mailto:[email protected]] >> Sent: Thursday, April 07, 2016 7:13 AM >> To: [email protected]; [email protected] >> Cc: Rooda, William (John.); Shvartsman, Oleg (O.I.); Hall, Todd (T.B.) >> Subject: Re: Cutting over to Java 7 >> >> Hi Marvin, >> >> Thanks for the input. You can find our discussion/vote thread from last >> month here: >> > http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAOqetn_vo69sx-yQjLt%3DQpfdRXgXVqu7NiobanLgXKOOr6Co0Q%40mail.gmail.com%3E >> >> The curious thing about your note - the WebSphere version I've seen the >> Ford team mention a few times requires Java 7. In general, EE 7 systems >> were built for Java 7 support (JMS made use of autocloseable is one I can >> think of off the top of my head). >> >> As mentioned, there's still a plan to support the 1.6.x line. If you > guys >> find any issues that you need to stay on 1.6.x, please feel free to raise >> them and we can address as additional 1.6.x patches. >> >> John >> On Thu, Apr 7, 2016 at 6:42 AM Marvin Toll <[email protected] >> <mailto:[email protected]>> wrote: >> A data point: Ford Motor Company is on Java 6. Given our portfolio of >> 4,000 applications (a subset of which are Java) - it is difficult to know >> how long a migration to Java 7 will take. It was scheduled to begin in >> calendar year 2016 - the current "begin" target is 2017. >> >> _Marvin >> >> -----Original Message----- >> From: John D. Ament [mailto:[email protected]<mailto: >> [email protected]>] >> Sent: Wednesday, April 6, 2016 10:14 PM >> To: deltaspike > <[email protected]<mailto:[email protected] >> >> >> Subject: Cutting over to Java 7 >> >> All, >> >> I wanted to get opinions for how to cut over to Java 7. >> >> There's two ways I've done similar cut overs in the past, wanted to > share >> them and build out some ideas. >> >> 1. Continue maintenance on 1.6 for x months. When we decide that we're >> going to cut a 1.7 we do the switch then. >> >> 2. Decide now that the next release is going to be planned as 1.7. If we >> need to do maintenance on 1.6 we branch from the tag and merge back in when >> done. >> >> The former is safer, but will take longer. The last minor release had the >> most patch releases on it, 4. The latter is more practical and shows >> implementation much quicker. It creates a bit more overhead as we'd > need >> to merge branches. In the 4.5 years of deltaspike, we haven't had to > do it >> thus yet. I suspect that given our user base, #2 would be acceptable since >> most everyone's using Java 7+, so it seems a small chance that we'd > run >> into a JVM difference. I'm not sure if others have different ideas to >> throw out. >> >> John >> >
