Re: Cutting over to Java 7

[Cody Lerum]

At this point it seems the main driver for dropping Java6 is to
discourage its use. I think there is sufficient discouragement
elsewhere and anyone with active or new projects is working towards or
planning for Java7/8.

+1 for keeping Java6 until the next major bump.

On Thu, Apr 7, 2016 at 7:25 AM, Mark Struberg  wrote:
> 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  
>> 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.) :
>>
>>>  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:johndam...@apache.org]
>>>  Sent: Thursday, April 07, 2016 7:13 AM
>>>  To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
>>>  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 >>  > 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:johndam...@apache.org>>  johndam...@apache.org>]
>>>  Sent: Wednesday, April 6, 2016 10:14 PM
>>>  To: deltaspike
>> mailto:dev@deltaspike.apache.org
>>>  >>
>>>  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
>>>
>>

Re: Cutting over to Java 7

[Gerhard Petracek]

@mark: +1

regards,
gerhard



2016-04-07 15:25 GMT+02:00 Mark Struberg :

> 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 
> 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.) :
> >
> >>  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:johndam...@apache.org]
> >>  Sent: Thursday, April 07, 2016 7:13 AM
> >>  To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
> >>  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  >>  > 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:johndam...@apache.org >>  johndam...@apache.org>]
> >>  Sent: Wednesday, April 6, 2016 10:14 PM
> >>  To: deltaspike
> > mailto:dev@deltaspike.apache.org
> >>  >>
> >>  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
> >>
> >
>

Re: Cutting over to Java 7

[Mark Struberg]

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  
> 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.) :
> 
>>  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:johndam...@apache.org]
>>  Sent: Thursday, April 07, 2016 7:13 AM
>>  To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
>>  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 >  > 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:johndam...@apache.org>  johndam...@apache.org>]
>>  Sent: Wednesday, April 6, 2016 10:14 PM
>>  To: deltaspike 
> mailto:dev@deltaspike.apache.org
>>  >>
>>  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
>> 
>

Re: Cutting over to Java 7

[Gerhard Petracek]

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.) :

> 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:johndam...@apache.org]
> Sent: Thursday, April 07, 2016 7:13 AM
> To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
> 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  > 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:johndam...@apache.org johndam...@apache.org>]
> Sent: Wednesday, April 6, 2016 10:14 PM
> To: deltaspike mailto:dev@deltaspike.apache.org
> >>
> 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
>

RE: Cutting over to Java 7

[Rooda, William (John.)]

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:johndam...@apache.org]
Sent: Thursday, April 07, 2016 7:13 AM
To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
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 
mailto:marvint...@gtcgroup.com>> 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:johndam...@apache.org]
Sent: Wednesday, April 6, 2016 10:14 PM
To: deltaspike mailto:dev@deltaspike.apache.org>>
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

RE: Cutting over to Java 7

[Marvin Toll]

Thanks John,

Believe me... I've been watching the thread closely.  :-)

I did not feel compelled to enter in until such time as it was being determined 
the approach for accommodation of Java 6 users.

You may have seen some POC code that is being used for preparation of our 
eventual move to Java 7 that we thought was going to begin this year???  
However, our standard data center offering remains WAS 8 (classic) with Java 6 
(at this time).

_Marvin

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Thursday, April 7, 2016 7:13 AM
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  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:johndam...@apache.org]
> Sent: Wednesday, April 6, 2016 10:14 PM
> To: deltaspike 
> 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
>
>

Re: Cutting over to Java 7

[John D. Ament]

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  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:johndam...@apache.org]
> Sent: Wednesday, April 6, 2016 10:14 PM
> To: deltaspike 
> 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
>
>

RE: Cutting over to Java 7

[Marvin Toll]

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:johndam...@apache.org] 
Sent: Wednesday, April 6, 2016 10:14 PM
To: deltaspike 
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