Re: Timescale for 8.0.x EOL

[Christopher Schultz]

All,

On 6/21/16 2:26 AM, jean-frederic clere wrote:
> On 06/20/2016 12:12 PM, Mark Thomas wrote:
>> Since it seems there is some interest in maintaining 8.0.x beyond
>> September, how about we announce that:
>> - the monthly release cycle for 8.0.x will end in September
>> - new features and bug fixes are unlikely to be back-ported from that
>>   point
>> - security fixes will probably be back-ported
>> - further releases will depend on circumstances but are unlikely to be
>>   more frequent that 6 monthly
>
> +1 I will try to find the cycles to be the RM from September on.

I forgot that we had had this discussion last year, but this topic came
back up at this week's TomcatCon.

I believe this was the general consensus from the community present this
week:

1. Tomcat 7.0.x is expected to be supported beyond the EOL for Tomcat
8.0.x. I don't believe there were any plans to sundown 7.0.x before
8.0.x, so this isn't a problem.

2. Tomcat 8.5.x should be a "nearly" drop-in replacement for Tomcat
8.0.x. Anything that prevents it from being so should be considered a
bug in Tomcat 8.5.x and should be fixed. There are one or two things
that could be changed in Tomcat 8.5.x to improve the current situation.

3. A migration guide pointing-out those items which can lead to Tomcat
8.5.x not being a drop-in replacement for Tomcat 8.0.x would be greatly
appreciated. Chris Schultz has graciously been voluntold to draft such a
guide. NB http://tomcat.apache.org/migration-85.html is too verbose;
users are looking for a "these items need to be addressed in order to do
a drop-in upgrade" kind of guide. The full migration guide can be used
when things don't work well after the short-short version.

4. Setting a definite EOL date is helpful because many vendors will not
even consider upgrading from e.g. 8.0.x -> 8.5.x unless there is an EOL
on the horizon. In order to force users to upgrade, we may be forced to
set this date as aggressively as possible. Conversely, 12 months is
about the amount of time that would be required for most users to plan,
test, and make the switch.

Given the above, I think it's probably safe to re-start the conversation
about setting an EOL date for Tomcat 8.0.x.

My proposal, adapted from the thread before discussion ceased last summer:

1. Set Tomcat 8.0.x EOL date for 31 May 2018
2. Discontinue monthly release cadence for Tomcat 8.0.x after 8.0.45
3. Make these announcements as soon as we have agreed to the details for
#1 and #2

-chris



signature.asc
Description: OpenPGP digital signature

JDK 9 EA Build 170 is available on jdk.java.net

[Rory O'Donnell]

Hi Mark, *

JDK 9 Early Access*  build 170  is available at the new location : - 
jdk.java.net/9/


A summary of all the changes in this build are listed here 
.


Changes which were introduced since the last availability email that may 
be of interest :


 * b168 - JDK-8175814: Update default HttpClient protocol version and
   optional request version
 o related to JEP 110  : HTTP/2 Client.
 * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
 o changes in command line options
 * b170 - JDK-8177153  : LambdaMetafactory has default
   constructorIncompatible change,
 o release note:  JDK-8180035

*New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev 
mailing list *[1]


 * Proposal: Allow illegal reflective access by default in JDK 9

   In short, the existing "big kill switch" of the `--permit-illegal-access`
   option [1] will become the default behavior of the JDK 9 run-time system,
   though without as many warnings.  The current behavior of JDK 9, in which
   illegal reflective-access operations from code on the class path are not
   permitted, will become the default in a future release.  Nothing will
   change at compile time.


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland