You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rémy Maucherat <re...@apache.org> on 2016/02/25 14:52:38 UTC
Tomcat 8.next
Hi,
This has been hinted at in the past, but is not being discussed anymore.
Possible options:
a) Release a new 8.x branch that would include the connectors from 9 to
support HTTP/2 [OpenSSL now allows realistic support without having to wait
for Java 9], and thus would remove a few legacy items.
b) A more radical option is to use 9 as 8.x but remove the Servlet API
changes. This would force Java 8 and many incompatible changes.
c) Give up on 8.x and instead release 9 as beta, then stable, with an
explicit exception about the Servlet 4 API additions being "preview" until
further notice. That's probably the solution which involves the least
effort by far.
d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
Servlet 4 is released. The main issue is that there's no HTTP/2 support
until then. The longer we wait, the more a major release will conflict with
the "intuitive" 9 release cycle in 2017.
Comments ?
Rémy
Re: Tomcat 8.next
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Rémy,
On 2/25/16 8:52 AM, Rémy Maucherat wrote:
> This has been hinted at in the past, but is not being discussed anymore.
>
> Possible options:
> a) Release a new 8.x branch that would include the connectors from 9 to
> support HTTP/2 [OpenSSL now allows realistic support without having to wait
> for Java 9], and thus would remove a few legacy items.
+1
> b) A more radical option is to use 9 as 8.x but remove the Servlet API
> changes. This would force Java 8 and many incompatible changes.
-0 depending upon the Java compatibility.
> c) Give up on 8.x and instead release 9 as beta, then stable, with an
> explicit exception about the Servlet 4 API additions being "preview" until
> further notice. That's probably the solution which involves the least
> effort by far.
-1
This will give us no stable up-to-date Tomcat supporting Servlet 3.1 (only).
It would be better to do option (b) and require Java 8 than to drop
Servlet 3.1.
> d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
> Servlet 4 is released. The main issue is that there's no HTTP/2 support
> until then. The longer we wait, the more a major release will conflict with
> the "intuitive" 9 release cycle in 2017.
-0
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by jean-frederic clere <jf...@gmail.com>.
On 02/25/2016 02:52 PM, Rémy Maucherat wrote:
> b) A more radical option is to use 9 as 8.x but remove the Servlet API
> changes. This would force Java 8 and many incompatible changes.
That looks the best for me, tomcat-8.5.x
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Anthony Biacco <ab...@handll.com>.
On Thu, Feb 25, 2016 at 11:01 PM, Huxing Zhang <hu...@alibaba-inc.com>
wrote:
> I'm +1 on backport HTTP/2 support to tomcat 8.
> I think this should fit into a).
Reasons:
> SPDY support has been supported until tomcat 8.0.22, and HTTP/2 is based
> on SPDY,
> so there should be no problem at Java language level.
>
>
If 8.0 is considered stable, I don't like the idea of introducing a large
feature into a stable release.
If anything i'd propose it be included into a 8.1 release which that minor
version, and any 8.1.x after it, is considered dev; until such time that
it's considered stable and then it folds into a stable 8.2 release, which
becomes the new 8.x stable.
Kind of like the tact kernel dev took with even minor releases being stable
and odd minor releases being dev (i don't know if this is still done)
Yes, it' makes the versioning and merge logistics more complex, but i think
it's the right thing to do if HTTP/2 must be in 8.x
-Tony
> Given that:
> 1. tomcat 8 has already dropped SPDY support
> 2. there are more and more web application who is willing to run on HTTP/2
> 3. tomcat 9 will not be release unless Servlet 4.0 is finalized.
>
> I think we should support HTTP/2 on tomcat 8.
>
> If the Java language level IS a problem, I propose another option:
>
> tomcat 8 WITH HTTP/2 requires to run on JAVA 8.
> tomcat 8 WITHOUT HTTP/2 requires to run on JAVA 7.
>
> This is similar to tomcat 7 + web socket support.
>
> Thanks,
> Huxing
>
> ------------------------------------------------------------------
> From:Rémy Maucherat <re...@apache.org>
> Time:2016 Feb 25 (Thu) 21:52
> To:Tomcat Developers List <de...@tomcat.apache.org>
> Subject:Tomcat 8.next
>
>
> Hi,
>
> This has been hinted at in the past, but is not being discussed anymore.
>
> Possible options:
> a) Release a new 8.x branch that would include the connectors from 9 to
> support HTTP/2 [OpenSSL now allows realistic support without having to wait
> for Java 9], and thus would remove a few legacy items.
> b) A more radical option is to use 9 as 8.x but remove the Servlet API
> changes. This would force Java 8 and many incompatible changes.
> c) Give up on 8.x and instead release 9 as beta, then stable, with an
> explicit exception about the Servlet 4 API additions being "preview" until
> further notice. That's probably the solution which involves the least
> effort by far.
> d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
> Servlet 4 is released. The main issue is that there's no HTTP/2 support
> until then. The longer we wait, the more a major release will conflict with
> the "intuitive" 9 release cycle in 2017.
>
> Comments ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat 8.next
Posted by Huxing Zhang <hu...@alibaba-inc.com>.
I'm +1 on backport HTTP/2 support to tomcat 8.
I think this should fit into a).
Reasons:
SPDY support has been supported until tomcat 8.0.22, and HTTP/2 is based on SPDY,
so there should be no problem at Java language level.
Given that:
1. tomcat 8 has already dropped SPDY support
2. there are more and more web application who is willing to run on HTTP/2
3. tomcat 9 will not be release unless Servlet 4.0 is finalized.
I think we should support HTTP/2 on tomcat 8.
If the Java language level IS a problem, I propose another option:
tomcat 8 WITH HTTP/2 requires to run on JAVA 8.
tomcat 8 WITHOUT HTTP/2 requires to run on JAVA 7.
This is similar to tomcat 7 + web socket support.
Thanks,
Huxing
------------------------------------------------------------------
From:Rémy Maucherat <re...@apache.org>
Time:2016 Feb 25 (Thu) 21:52
To:Tomcat Developers List <de...@tomcat.apache.org>
Subject:Tomcat 8.next
Hi,
This has been hinted at in the past, but is not being discussed anymore.
Possible options:
a) Release a new 8.x branch that would include the connectors from 9 to
support HTTP/2 [OpenSSL now allows realistic support without having to wait
for Java 9], and thus would remove a few legacy items.
b) A more radical option is to use 9 as 8.x but remove the Servlet API
changes. This would force Java 8 and many incompatible changes.
c) Give up on 8.x and instead release 9 as beta, then stable, with an
explicit exception about the Servlet 4 API additions being "preview" until
further notice. That's probably the solution which involves the least
effort by far.
d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
Servlet 4 is released. The main issue is that there's no HTTP/2 support
until then. The longer we wait, the more a major release will conflict with
the "intuitive" 9 release cycle in 2017.
Comments ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Violeta Georgieva <mi...@gmail.com>.
2016-03-02 12:37 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> On 02/03/2016 10:26, Rémy Maucherat wrote:
> > 2016-03-02 10:24 GMT+01:00 Mark Thomas <ma...@apache.org>:
> >
> >> We could add a (deprecated) PushBuilder interface to o.a.catalina so
all
> >> users would have to do is rename the import to move from 8.5.x to
9.0.x.
> >>
> >> Users would also have to cast the request object in order to call
> >> getPushBuilder().
> >>
> >> Not perfect but not awful considering this is early access to Servlet
> >> 4.0 API and that that API could change anyway.
> >>
> > Yes, same, although I don't really see a big value add with using an
> > interim o.a.catalina.PushBuilder interface over ApplicationPushBuilder.
But
> > it's a detail, I'm fine with it if you prefer it.
>
> I'm not sure I do prefer it. It was more a suggestion. I'm not sure it
> is worth it. The required search and replace is going to be trivial
> either way.
>
> > Next decision is when to branch ? If doing b) a 8.5.x branch will need
to
> > be created from the main trunk.
>
> How about this for a plan?
>
> Copy the tag for the next 9.0.x release to create the 8.5.x branch.
>
> Fix the various issues (Java 7, API, etc) and release 8.5.0 alpha
> shortly after 9.0.next.
+1
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-02 11:37 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 02/03/2016 10:26, Rémy Maucherat wrote:
> > 2016-03-02 10:24 GMT+01:00 Mark Thomas <ma...@apache.org>:
> >
> >> We could add a (deprecated) PushBuilder interface to o.a.catalina so all
> >> users would have to do is rename the import to move from 8.5.x to 9.0.x.
> >>
> >> Users would also have to cast the request object in order to call
> >> getPushBuilder().
> >>
> >> Not perfect but not awful considering this is early access to Servlet
> >> 4.0 API and that that API could change anyway.
> >>
> > Yes, same, although I don't really see a big value add with using an
> > interim o.a.catalina.PushBuilder interface over ApplicationPushBuilder.
> But
> > it's a detail, I'm fine with it if you prefer it.
>
> I'm not sure I do prefer it. It was more a suggestion. I'm not sure it
> is worth it. The required search and replace is going to be trivial
> either way.
>
> > Next decision is when to branch ? If doing b) a 8.5.x branch will need to
> > be created from the main trunk.
>
> How about this for a plan?
>
> Copy the tag for the next 9.0.x release to create the 8.5.x branch.
>
> Fix the various issues (Java 7, API, etc) and release 8.5.0 alpha
> shortly after 9.0.next.
>
> +1
Rémy
Re: Tomcat 8.next
Posted by Mark Thomas <ma...@apache.org>.
On 02/03/2016 10:26, Rémy Maucherat wrote:
> 2016-03-02 10:24 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
>> We could add a (deprecated) PushBuilder interface to o.a.catalina so all
>> users would have to do is rename the import to move from 8.5.x to 9.0.x.
>>
>> Users would also have to cast the request object in order to call
>> getPushBuilder().
>>
>> Not perfect but not awful considering this is early access to Servlet
>> 4.0 API and that that API could change anyway.
>>
> Yes, same, although I don't really see a big value add with using an
> interim o.a.catalina.PushBuilder interface over ApplicationPushBuilder. But
> it's a detail, I'm fine with it if you prefer it.
I'm not sure I do prefer it. It was more a suggestion. I'm not sure it
is worth it. The required search and replace is going to be trivial
either way.
> Next decision is when to branch ? If doing b) a 8.5.x branch will need to
> be created from the main trunk.
How about this for a plan?
Copy the tag for the next 9.0.x release to create the 8.5.x branch.
Fix the various issues (Java 7, API, etc) and release 8.5.0 alpha
shortly after 9.0.next.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-02 10:24 GMT+01:00 Mark Thomas <ma...@apache.org>:
> We could add a (deprecated) PushBuilder interface to o.a.catalina so all
> users would have to do is rename the import to move from 8.5.x to 9.0.x.
>
> Users would also have to cast the request object in order to call
> getPushBuilder().
>
> Not perfect but not awful considering this is early access to Servlet
> 4.0 API and that that API could change anyway.
>
> Yes, same, although I don't really see a big value add with using an
interim o.a.catalina.PushBuilder interface over ApplicationPushBuilder. But
it's a detail, I'm fine with it if you prefer it.
Next decision is when to branch ? If doing b) a 8.5.x branch will need to
be created from the main trunk.
Rémy
Re: Tomcat 8.next
Posted by Mark Thomas <ma...@apache.org>.
On 02/03/2016 09:13, Rémy Maucherat wrote:
> 2016-03-02 9:56 GMT+01:00 jean-frederic clere <jf...@gmail.com>:
>
>> On 03/01/2016 11:30 PM, Rémy Maucherat wrote:
>>> 2016-03-01 23:12 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>>
>>>> To summarise where I think this discussion is going:
>>>>
>>>> - Create 8.5.x from 9.0.x with the following changes
>>>> - revert all changes to spec APIs
>>>>
>>>
>>> Yes. Do we have a plan when everyone wants to do a push ? (I'm really
>> not a
>>> fan of it ...)
>>
>> Through a "private" API until we do 9?
>>
> The public interface can be removed, the implementation remains. But
> obviously it becomes harder to use.
> PushBuilder -> o.a.catalina.core.ApplicationPushBuilder
We could add a (deprecated) PushBuilder interface to o.a.catalina so all
users would have to do is rename the import to move from 8.5.x to 9.0.x.
Users would also have to cast the request object in order to call
getPushBuilder().
Not perfect but not awful considering this is early access to Servlet
4.0 API and that that API could change anyway.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-02 9:56 GMT+01:00 jean-frederic clere <jf...@gmail.com>:
> On 03/01/2016 11:30 PM, Rémy Maucherat wrote:
> > 2016-03-01 23:12 GMT+01:00 Mark Thomas <ma...@apache.org>:
> >
> >> To summarise where I think this discussion is going:
> >>
> >> - Create 8.5.x from 9.0.x with the following changes
> >> - revert all changes to spec APIs
> >>
> >
> > Yes. Do we have a plan when everyone wants to do a push ? (I'm really
> not a
> > fan of it ...)
>
> Through a "private" API until we do 9?
>
> The public interface can be removed, the implementation remains. But
obviously it becomes harder to use.
PushBuilder -> o.a.catalina.core.ApplicationPushBuilder
Rémy
Re: Tomcat 8.next
Posted by jean-frederic clere <jf...@gmail.com>.
On 03/01/2016 11:30 PM, Rémy Maucherat wrote:
> 2016-03-01 23:12 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
>> To summarise where I think this discussion is going:
>>
>> - Create 8.5.x from 9.0.x with the following changes
>> - revert all changes to spec APIs
>>
>
> Yes. Do we have a plan when everyone wants to do a push ? (I'm really not a
> fan of it ...)
Through a "private" API until we do 9?
Cheers
Jean-Frederic
>
>
>> - make any necessary changes to work with Java 7
>>
>> - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
>> releases
>>
>> - If users report problems caused by removal of a deprecated API in
>> 8.5.x, restore it.
>>
>> Did I miss anything? Any additional concerns to address?
>>
>> That sounds good !
>
> Rémy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-01 23:12 GMT+01:00 Mark Thomas <ma...@apache.org>:
> To summarise where I think this discussion is going:
>
> - Create 8.5.x from 9.0.x with the following changes
> - revert all changes to spec APIs
>
Yes. Do we have a plan when everyone wants to do a push ? (I'm really not a
fan of it ...)
> - make any necessary changes to work with Java 7
>
> - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
> releases
>
> - If users report problems caused by removal of a deprecated API in
> 8.5.x, restore it.
>
> Did I miss anything? Any additional concerns to address?
>
> That sounds good !
Rémy
RE: Tomcat 8.next
Posted by Larry Isaacs <La...@sas.com>.
FYI: Support for Tomcat 9.0 was added to WTP 3.8 for Eclipse Neon last weekend.
I can add 8.5 support, but it would be best if it could be added in March or April. If it's delayed beyond that, it might have to move to the first maintenance release that comes out in late September. I'll try to keep an eye on this.
Cheers,
Larry
-----Original Message-----
From: Rémy Maucherat [mailto:remm@apache.org]
Sent: Wed, March 02, 2016 8:43 AM
To: Tomcat Developers List <de...@tomcat.apache.org>
Subject: Re: Tomcat 8.next
2016-03-02 13:15 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
> 2016-03-02 1:12 GMT+03:00 Mark Thomas <ma...@apache.org>:
> > To summarise where I think this discussion is going:
> >
> > - Create 8.5.x from 9.0.x with the following changes
> > - revert all changes to spec APIs
> > - make any necessary changes to work with Java 7
> >
> > - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
> > releases
> >
> > - If users report problems caused by removal of a deprecated API in
> > 8.5.x, restore it.
> >
> > Did I miss anything? Any additional concerns to address?
>
> The plan looks good.
>
> Concerns:
> 1. Eclipse IDE has 1 year cycle of major releases. If we go in March,
> I think we have chances to have 8.5 support in next major release this
> summer. (Provided that somebody does an effort to actually implement
> it, as with any volunteer work).
>
> I think that 6 months are counted from first stable release, not from
> 8.5.alpha.
>
> This time interval of 6 months sounds right for major adoption, but as
> we have always provided a 1 year advance notice of EOL I think we
> should be ready to provide security fixes and such for 1 year. These
> releases should not be monthly (as with current 8.0), but occasional
> ones. E.g. once in 3-6 months.
>
The "base" 6 months after a stable release seems ok to me. Hoepfully the road to stable isn't too long though.
>
>
> 2. The feature of auto-switching sslImplementationName with
> availability of TCNative library needs better documentation. I suspect
> that it may come as a surprise.
>
> There is documentation of sslImplementationName attribute on
> config/http.html, but the attribute of AprLifecycleListener
> (useAprConnector) is not documented at all.
>
It is supposed to be documented as of r1729644. OTOH, I'm not that good with that kind of thing, and maybe it is still confusing.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-09 10:39 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
> 2016-03-02 16:42 GMT+03:00 Rémy Maucherat <re...@apache.org>:
> > 2016-03-02 13:15 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
> >>
> >>
> >> 2. The feature of auto-switching sslImplementationName with
> >> availability of TCNative library needs better documentation. I suspect
> >> that it may come as a surprise.
> >>
> >> There is documentation of sslImplementationName attribute on
> >> config/http.html, but the attribute of AprLifecycleListener
> >> (useAprConnector) is not documented at all.
> >>
> >
> > It is supposed to be documented as of r1729644. OTOH, I'm not that good
> > with that kind of thing, and maybe it is still confusing.
> >
>
> Thank you for the pointer. It is better than I thought.
>
> As for the missing parts, I filed an issue into Bugzilla,
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59150
>
> Ok, I see the duplication, I'll fix that.
Rémy
Re: Tomcat 8.next
Posted by Konstantin Kolinko <kn...@gmail.com>.
2016-03-02 16:42 GMT+03:00 Rémy Maucherat <re...@apache.org>:
> 2016-03-02 13:15 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
>>
>>
>> 2. The feature of auto-switching sslImplementationName with
>> availability of TCNative library needs better documentation. I suspect
>> that it may come as a surprise.
>>
>> There is documentation of sslImplementationName attribute on
>> config/http.html, but the attribute of AprLifecycleListener
>> (useAprConnector) is not documented at all.
>>
>
> It is supposed to be documented as of r1729644. OTOH, I'm not that good
> with that kind of thing, and maybe it is still confusing.
>
Thank you for the pointer. It is better than I thought.
As for the missing parts, I filed an issue into Bugzilla,
https://bz.apache.org/bugzilla/show_bug.cgi?id=59150
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-02 13:15 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
> 2016-03-02 1:12 GMT+03:00 Mark Thomas <ma...@apache.org>:
> > To summarise where I think this discussion is going:
> >
> > - Create 8.5.x from 9.0.x with the following changes
> > - revert all changes to spec APIs
> > - make any necessary changes to work with Java 7
> >
> > - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
> > releases
> >
> > - If users report problems caused by removal of a deprecated API in
> > 8.5.x, restore it.
> >
> > Did I miss anything? Any additional concerns to address?
>
> The plan looks good.
>
> Concerns:
> 1. Eclipse IDE has 1 year cycle of major releases. If we go in March,
> I think we have chances to have 8.5 support in next major release this
> summer. (Provided that somebody does an effort to actually implement
> it, as with any volunteer work).
>
> I think that 6 months are counted from first stable release, not from
> 8.5.alpha.
>
> This time interval of 6 months sounds right for major adoption, but as
> we have always provided a 1 year advance notice of EOL I think we
> should be ready to provide security fixes and such for 1 year. These
> releases should not be monthly (as with current 8.0), but occasional
> ones. E.g. once in 3-6 months.
>
The "base" 6 months after a stable release seems ok to me. Hoepfully the
road to stable isn't too long though.
>
>
> 2. The feature of auto-switching sslImplementationName with
> availability of TCNative library needs better documentation. I suspect
> that it may come as a surprise.
>
> There is documentation of sslImplementationName attribute on
> config/http.html, but the attribute of AprLifecycleListener
> (useAprConnector) is not documented at all.
>
It is supposed to be documented as of r1729644. OTOH, I'm not that good
with that kind of thing, and maybe it is still confusing.
Rémy
Re: Tomcat 8.next
Posted by Konstantin Kolinko <kn...@gmail.com>.
2016-03-02 1:12 GMT+03:00 Mark Thomas <ma...@apache.org>:
> To summarise where I think this discussion is going:
>
> - Create 8.5.x from 9.0.x with the following changes
> - revert all changes to spec APIs
> - make any necessary changes to work with Java 7
>
> - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
> releases
>
> - If users report problems caused by removal of a deprecated API in
> 8.5.x, restore it.
>
> Did I miss anything? Any additional concerns to address?
The plan looks good.
Concerns:
1. Eclipse IDE has 1 year cycle of major releases. If we go in March,
I think we have chances to have 8.5 support in next major release this
summer. (Provided that somebody does an effort to actually implement
it, as with any volunteer work).
I think that 6 months are counted from first stable release, not from 8.5.alpha.
This time interval of 6 months sounds right for major adoption, but as
we have always provided a 1 year advance notice of EOL I think we
should be ready to provide security fixes and such for 1 year. These
releases should not be monthly (as with current 8.0), but occasional
ones. E.g. once in 3-6 months.
2. The feature of auto-switching sslImplementationName with
availability of TCNative library needs better documentation. I suspect
that it may come as a surprise.
There is documentation of sslImplementationName attribute on
config/http.html, but the attribute of AprLifecycleListener
(useAprConnector) is not documented at all.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-03 21:20 GMT+01:00 Mark Thomas <ma...@apache.org>:
> One thought I had for BIO support was that we could add something like
> this to handle the case where the user has explicitly selected BIO
>
> public class Http11Protocol extends Http11NioProtocol {
>
> public Http11Protocol() {
> super();
> log.warn("BIO connector removed. Using NIO instead.");
> }
> }
>
>
> And the same for AJP.
>
> So since it is not the default, it could have been manually overridden. If
that's been done, startup will fail and manual configuration is needed, I'm
not sure this is that bad though.
Rémy
Re: Tomcat 8.next
Posted by Mark Thomas <ma...@apache.org>.
On 03/03/2016 16:41, Mark Thomas wrote:
> On 03/03/2016 15:41, Christopher Schultz wrote:
>> Mark,
>>
>> On 3/1/16 5:12 PM, Mark Thomas wrote:
>>> To summarise where I think this discussion is going:
>>>
>>> - Create 8.5.x from 9.0.x with the following changes
>>> - revert all changes to spec APIs
>>
>> I would argue that anything that has been added (in TC9) can stay; only
>> revert the removals and possibly any deprecations.
>
> There are no removals.
>
> The spec APIs have to be correct. Our spec API JARs are used in various
> places and if we starting shipping a Servlet 3.1+ API we'll create the
> potential to cause all sorts of problems.
>
>>> - make any necessary changes to work with Java 7
>>>
>>> - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
>>> releases
>>
>> Does this have implications for whether or not we can claim
>> spec-compatibility? Tomcat 8.5 would be
>> servlet-3.1-except-for-that-Java-7-support-thing... so can we claim that
>> Tomcat 8.5 officially supports the servlet 3.1 specification? Do we even
>> care?
>
> 8.5 will be as spec compliant as 8.0.
> - It will run on Java 7.
> - The spec APIs will be identical between versions.
> - It will, as far as we know, be compliant with all
> four specs it implements
>
> We haven't had access to the TCK for quite some time. It is a useful
> additional check that in an ideal world I'd like to have back but not
> having it doesn't appear to be causing the project any harm.
One thought I had for BIO support was that we could add something like
this to handle the case where the user has explicitly selected BIO
public class Http11Protocol extends Http11NioProtocol {
public Http11Protocol() {
super();
log.warn("BIO connector removed. Using NIO instead.");
}
}
And the same for AJP.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Mark Thomas <ma...@apache.org>.
On 03/03/2016 15:41, Christopher Schultz wrote:
> Mark,
>
> On 3/1/16 5:12 PM, Mark Thomas wrote:
>> To summarise where I think this discussion is going:
>>
>> - Create 8.5.x from 9.0.x with the following changes
>> - revert all changes to spec APIs
>
> I would argue that anything that has been added (in TC9) can stay; only
> revert the removals and possibly any deprecations.
There are no removals.
The spec APIs have to be correct. Our spec API JARs are used in various
places and if we starting shipping a Servlet 3.1+ API we'll create the
potential to cause all sorts of problems.
>> - make any necessary changes to work with Java 7
>>
>> - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
>> releases
>
> Does this have implications for whether or not we can claim
> spec-compatibility? Tomcat 8.5 would be
> servlet-3.1-except-for-that-Java-7-support-thing... so can we claim that
> Tomcat 8.5 officially supports the servlet 3.1 specification? Do we even
> care?
8.5 will be as spec compliant as 8.0.
- It will run on Java 7.
- The spec APIs will be identical between versions.
- It will, as far as we know, be compliant with all
four specs it implements
We haven't had access to the TCK for quite some time. It is a useful
additional check that in an ideal world I'd like to have back but not
having it doesn't appear to be causing the project any harm.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-03-03 16:41 GMT+01:00 Christopher Schultz <chris@christopherschultz.net
>:
> Mark,
>
> On 3/1/16 5:12 PM, Mark Thomas wrote:
> > To summarise where I think this discussion is going:
> >
> > - Create 8.5.x from 9.0.x with the following changes
> > - revert all changes to spec APIs
>
> I would argue that anything that has been added (in TC9) can stay; only
> revert the removals and possibly any deprecations.
>
The plan is not to proactively revert all removals of items deprecated in
TC 8.0.x, only those people will actually complain about.
>
> > - make any necessary changes to work with Java 7
> >
> > - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
> > releases
>
> Does this have implications for whether or not we can claim
> spec-compatibility? Tomcat 8.5 would be
> servlet-3.1-except-for-that-Java-7-support-thing... so can we claim that
> Tomcat 8.5 officially supports the servlet 3.1 specification? Do we even
> care?
>
Yes, the Servlet 4 API will likely change and this would mean we'd have to
beak things. It the Servlet 4 API items are removed, then people can use
the equivalent proprietary Catalina classes that can stay unchanged in
Tomcat 8.5. This is not related to the TCK because the ASF has no access to
it.
>
> > - If users report problems caused by removal of a deprecated API in
> > 8.5.x, restore it.
> >
> > Did I miss anything? Any additional concerns to address?
>
> Rémy
Re: Tomcat 8.next
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 3/1/16 5:12 PM, Mark Thomas wrote:
> To summarise where I think this discussion is going:
>
> - Create 8.5.x from 9.0.x with the following changes
> - revert all changes to spec APIs
I would argue that anything that has been added (in TC9) can stay; only
revert the removals and possibly any deprecations.
> - make any necessary changes to work with Java 7
>
> - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
> releases
Does this have implications for whether or not we can claim
spec-compatibility? Tomcat 8.5 would be
servlet-3.1-except-for-that-Java-7-support-thing... so can we claim that
Tomcat 8.5 officially supports the servlet 3.1 specification? Do we even
care?
> - If users report problems caused by removal of a deprecated API in
> 8.5.x, restore it.
>
> Did I miss anything? Any additional concerns to address?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Violeta Georgieva <mi...@gmail.com>.
Hi,
2016-03-02 0:12 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> To summarise where I think this discussion is going:
>
> - Create 8.5.x from 9.0.x with the following changes
> - revert all changes to spec APIs
> - make any necessary changes to work with Java 7
>
> - Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
> releases
>
> - If users report problems caused by removal of a deprecated API in
> 8.5.x, restore it.
>
> Did I miss anything? Any additional concerns to address?
Let's do it.
Regards,
Violeta
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: Tomcat 8.next
Posted by Mark Thomas <ma...@apache.org>.
To summarise where I think this discussion is going:
- Create 8.5.x from 9.0.x with the following changes
- revert all changes to spec APIs
- make any necessary changes to work with Java 7
- Release 8.0.x and 8.5.x in parallel for ~6 months then stop 8.0.x
releases
- If users report problems caused by removal of a deprecated API in
8.5.x, restore it.
Did I miss anything? Any additional concerns to address?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rainer Jung <ra...@kippdata.de>.
Am 29.02.2016 um 14:00 schrieb Rémy Maucherat:
> 2016-02-28 14:09 GMT+01:00 Rainer Jung <ra...@kippdata.de>:
>
>>
>> I find it hard to judge between a) and b), because I don't know much about
>> the gap between only merging the connectors and merging anything but not
>> Servlet API. I think making HTTP/2 and also OpenSSL support in HTTPS
>> connectors available is important enough to warrant not waiting for the
>> final Servlet Spec / TC 9. The biggest other change I see is the removal of
>> BIO.
>>
>> Concerning Java 7 vs. 8 it would be nice to allow the split as it was done
>> with web sockets in TC 7. But it is not critical. Java 7 public updates
>> ended 10 months ago. People who are not yet on TC 8 and who want or need to
>> stay on Java 7 can stick to TC 7.
>>
>> People who need HTTP/2 should be prepared to use latest and greatest. For
>> them a switch to Java 8 should not really be a problem.
>>
>> The problematic part is the people who just migrated to TC 8 during the
>> last 2 years and might still need to use Java 7 for some reasons. Those are
>> the ones that should guide the time we are willing to support 8 and 8.next
>> in parallel. So IMHO the time depends somewhat on the Java 7/8 result and
>> also the a)/b) decision (how compatible are 8 and 8.next) and also on the
>> timing (announcement of plan, first release of 8.next GA). 6 months is not
>> much for people who just moved to TC 8 if the update to 8.next involves
>> noticeable work on their side.
>>
>> So the Java 7 issue could be resolved :) It's not really supported
> anymore, but it's obvious that's the biggest concern for everyone.
>
> The main other difference between a) and b) is that some items marked as
> deprecated in 8 are removed in 9. I don't think it affects items that are
> actually used a lot. Any problematic items can be restored easily if needed.
>
> Personally, I think I prefer b) now, as a) would mean porting the
> connectors with a lot of changes including behavior changes, and this could
> have some compatibility issues that could be harder to detect.
Thanks for the explanation. Agreed.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-02-28 14:09 GMT+01:00 Rainer Jung <ra...@kippdata.de>:
>
> I find it hard to judge between a) and b), because I don't know much about
> the gap between only merging the connectors and merging anything but not
> Servlet API. I think making HTTP/2 and also OpenSSL support in HTTPS
> connectors available is important enough to warrant not waiting for the
> final Servlet Spec / TC 9. The biggest other change I see is the removal of
> BIO.
>
> Concerning Java 7 vs. 8 it would be nice to allow the split as it was done
> with web sockets in TC 7. But it is not critical. Java 7 public updates
> ended 10 months ago. People who are not yet on TC 8 and who want or need to
> stay on Java 7 can stick to TC 7.
>
> People who need HTTP/2 should be prepared to use latest and greatest. For
> them a switch to Java 8 should not really be a problem.
>
> The problematic part is the people who just migrated to TC 8 during the
> last 2 years and might still need to use Java 7 for some reasons. Those are
> the ones that should guide the time we are willing to support 8 and 8.next
> in parallel. So IMHO the time depends somewhat on the Java 7/8 result and
> also the a)/b) decision (how compatible are 8 and 8.next) and also on the
> timing (announcement of plan, first release of 8.next GA). 6 months is not
> much for people who just moved to TC 8 if the update to 8.next involves
> noticeable work on their side.
>
> So the Java 7 issue could be resolved :) It's not really supported
anymore, but it's obvious that's the biggest concern for everyone.
The main other difference between a) and b) is that some items marked as
deprecated in 8 are removed in 9. I don't think it affects items that are
actually used a lot. Any problematic items can be restored easily if needed.
Personally, I think I prefer b) now, as a) would mean porting the
connectors with a lot of changes including behavior changes, and this could
have some compatibility issues that could be harder to detect.
Rémy
Re: Tomcat 8.next
Posted by Mark Thomas <ma...@apache.org>.
On 28/02/2016 13:09, Rainer Jung wrote:
<snip/>
> Concerning Java 7 vs. 8 it would be nice to allow the split as it was
> done with web sockets in TC 7. But it is not critical. Java 7 public
> updates ended 10 months ago. People who are not yet on TC 8 and who want
> or need to stay on Java 7 can stick to TC 7.
>
> People who need HTTP/2 should be prepared to use latest and greatest.
> For them a switch to Java 8 should not really be a problem.
I don't think we need to worry about Java 7 vs. Java 8. I'm confident
we'll be able to back-port the Java 8 specific code to Java 7.
> The problematic part is the people who just migrated to TC 8 during the
> last 2 years and might still need to use Java 7 for some reasons. Those
> are the ones that should guide the time we are willing to support 8 and
> 8.next in parallel. So IMHO the time depends somewhat on the Java 7/8
> result and also the a)/b) decision (how compatible are 8 and 8.next) and
> also on the timing (announcement of plan, first release of 8.next GA). 6
> months is not much for people who just moved to TC 8 if the update to
> 8.next involves noticeable work on their side.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rainer Jung <ra...@kippdata.de>.
Am 25.02.2016 um 15:15 schrieb Mark Thomas:
> On 25/02/2016 13:52, Rémy Maucherat wrote:
>> Hi,
>>
>> This has been hinted at in the past, but is not being discussed anymore.
>>
>> Possible options:
>> a) Release a new 8.x branch that would include the connectors from 9 to
>> support HTTP/2 [OpenSSL now allows realistic support without having to wait
>> for Java 9], and thus would remove a few legacy items.
>
> This should be doable but we'd need to think about the how to make sure
> we didn't loose history for code that becomes 8.1.x.
>
>> b) A more radical option is to use 9 as 8.x but remove the Servlet API
>> changes. This would force Java 8 and many incompatible changes.
>
> Eclipse tells me there are ~200 errors if I try to build Tomcat 9 with
> Java 7. Those errors have maybe a handful of root causes of which only
> one looks to be non-trivial (http2.FrameType) but even that is a
> relatively simple fix.
>
> The Java 7 issues look solvable. That there are *lots* of other API
> changes and that is likely to be more significant.
>
>> c) Give up on 8.x and instead release 9 as beta, then stable, with an
>> explicit exception about the Servlet 4 API additions being "preview" until
>> further notice. That's probably the solution which involves the least
>> effort by far.
>
> I assume you mean give up on 8.next and continue to maintain 8.0.x.
>
>> d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
>> Servlet 4 is released. The main issue is that there's no HTTP/2 support
>> until then. The longer we wait, the more a major release will conflict with
>> the "intuitive" 9 release cycle in 2017.
>
>
> I don't see any other options than the ones you propose.
>
> Of those options I prefer option b) at the moment. We should probably
> call it 8.5 since the degree of API change is significant - like it was
> in 5.0 to 5.5.
>
> After that, I have roughly equal preference for a) or c). a) was what I
> originally had in mind but b) has since started to look more attractive.
>
> I don't think d) is a viable option. It leaves the new features in 9.0.x
> in alpha for too long.
>
> Regardless of the option we choose, an open question is how long do we
> support 8.0 in parallel with 8.next? For 5.0/5.5 it was about 2 months.
> I'd be prepared to do release management in parallel for ~6 months.
I find it hard to judge between a) and b), because I don't know much
about the gap between only merging the connectors and merging anything
but not Servlet API. I think making HTTP/2 and also OpenSSL support in
HTTPS connectors available is important enough to warrant not waiting
for the final Servlet Spec / TC 9. The biggest other change I see is the
removal of BIO.
Concerning Java 7 vs. 8 it would be nice to allow the split as it was
done with web sockets in TC 7. But it is not critical. Java 7 public
updates ended 10 months ago. People who are not yet on TC 8 and who want
or need to stay on Java 7 can stick to TC 7.
People who need HTTP/2 should be prepared to use latest and greatest.
For them a switch to Java 8 should not really be a problem.
The problematic part is the people who just migrated to TC 8 during the
last 2 years and might still need to use Java 7 for some reasons. Those
are the ones that should guide the time we are willing to support 8 and
8.next in parallel. So IMHO the time depends somewhat on the Java 7/8
result and also the a)/b) decision (how compatible are 8 and 8.next) and
also on the timing (announcement of plan, first release of 8.next GA). 6
months is not much for people who just moved to TC 8 if the update to
8.next involves noticeable work on their side.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 8.next
Posted by Rémy Maucherat <re...@apache.org>.
2016-02-25 15:15 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 25/02/2016 13:52, Rémy Maucherat wrote:
> > Hi,
> >
> > This has been hinted at in the past, but is not being discussed anymore.
> >
> > Possible options:
> > a) Release a new 8.x branch that would include the connectors from 9 to
> > support HTTP/2 [OpenSSL now allows realistic support without having to
> wait
> > for Java 9], and thus would remove a few legacy items.
>
> This should be doable but we'd need to think about the how to make sure
> we didn't loose history for code that becomes 8.1.x.
>
> > b) A more radical option is to use 9 as 8.x but remove the Servlet API
> > changes. This would force Java 8 and many incompatible changes.
>
> Eclipse tells me there are ~200 errors if I try to build Tomcat 9 with
> Java 7. Those errors have maybe a handful of root causes of which only
> one looks to be non-trivial (http2.FrameType) but even that is a
> relatively simple fix.
>
> The Java 7 issues look solvable. That there are *lots* of other API
> changes and that is likely to be more significant.
>
Ok, so b) could still use Java 7, hopefully. The main downside is a lot of
breakage for a "same major branch" release since there was a lot of
deprecation removals.
>
> > c) Give up on 8.x and instead release 9 as beta, then stable, with an
> > explicit exception about the Servlet 4 API additions being "preview"
> until
> > further notice. That's probably the solution which involves the least
> > effort by far.
>
> I assume you mean give up on 8.next and continue to maintain 8.0.x.
>
Yes, obviously, this only means give up on a new 8.x branch :)
>
> > d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
> > Servlet 4 is released. The main issue is that there's no HTTP/2 support
> > until then. The longer we wait, the more a major release will conflict
> with
> > the "intuitive" 9 release cycle in 2017.
>
>
> I don't see any other options than the ones you propose.
>
> Of those options I prefer option b) at the moment. We should probably
> call it 8.5 since the degree of API change is significant - like it was
> in 5.0 to 5.5.
>
> After that, I have roughly equal preference for a) or c). a) was what I
> originally had in mind but b) has since started to look more attractive.
>
> I don't think d) is a viable option. It leaves the new features in 9.0.x
> in alpha for too long.
>
> Regardless of the option we choose, an open question is how long do we
> support 8.0 in parallel with 8.next? For 5.0/5.5 it was about 2 months.
> I'd be prepared to do release management in parallel for ~6 months.
>
> At that time, there was less emphasis on long term support, since major
version came more quickly and each new one had really desirable features (a
bit like HTTP/2 now).
Rémy
Re: Tomcat 8.next
Posted by Violeta Georgieva <mi...@gmail.com>.
Hi,
2016-02-25 16:15 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> On 25/02/2016 13:52, Rémy Maucherat wrote:
> > Hi,
> >
> > This has been hinted at in the past, but is not being discussed anymore.
> >
> > Possible options:
> > a) Release a new 8.x branch that would include the connectors from 9 to
> > support HTTP/2 [OpenSSL now allows realistic support without having to
wait
> > for Java 9], and thus would remove a few legacy items.
>
> This should be doable but we'd need to think about the how to make sure
> we didn't loose history for code that becomes 8.1.x.
>
> > b) A more radical option is to use 9 as 8.x but remove the Servlet API
> > changes. This would force Java 8 and many incompatible changes.
>
> Eclipse tells me there are ~200 errors if I try to build Tomcat 9 with
> Java 7. Those errors have maybe a handful of root causes of which only
> one looks to be non-trivial (http2.FrameType) but even that is a
> relatively simple fix.
>
> The Java 7 issues look solvable. That there are *lots* of other API
> changes and that is likely to be more significant.
>
> > c) Give up on 8.x and instead release 9 as beta, then stable, with an
> > explicit exception about the Servlet 4 API additions being "preview"
until
> > further notice. That's probably the solution which involves the least
> > effort by far.
>
> I assume you mean give up on 8.next and continue to maintain 8.0.x.
>
> > d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
> > Servlet 4 is released. The main issue is that there's no HTTP/2 support
> > until then. The longer we wait, the more a major release will conflict
with
> > the "intuitive" 9 release cycle in 2017.
>
>
> I don't see any other options than the ones you propose.
>
> Of those options I prefer option b) at the moment. We should probably
> call it 8.5 since the degree of API change is significant - like it was
> in 5.0 to 5.5.
+1 for b) option
may be the usage of lambdas were the failures that you've seen with Java 7
build.
>
> After that, I have roughly equal preference for a) or c). a) was what I
> originally had in mind but b) has since started to look more attractive.
>
> I don't think d) is a viable option. It leaves the new features in 9.0.x
> in alpha for too long.
>
> Regardless of the option we choose, an open question is how long do we
> support 8.0 in parallel with 8.next? For 5.0/5.5 it was about 2 months.
> I'd be prepared to do release management in parallel for ~6 months.
+1 6 months sounds OK for me
Regards,
Violeta
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: Tomcat 8.next
Posted by Mark Thomas <ma...@apache.org>.
On 25/02/2016 13:52, Rémy Maucherat wrote:
> Hi,
>
> This has been hinted at in the past, but is not being discussed anymore.
>
> Possible options:
> a) Release a new 8.x branch that would include the connectors from 9 to
> support HTTP/2 [OpenSSL now allows realistic support without having to wait
> for Java 9], and thus would remove a few legacy items.
This should be doable but we'd need to think about the how to make sure
we didn't loose history for code that becomes 8.1.x.
> b) A more radical option is to use 9 as 8.x but remove the Servlet API
> changes. This would force Java 8 and many incompatible changes.
Eclipse tells me there are ~200 errors if I try to build Tomcat 9 with
Java 7. Those errors have maybe a handful of root causes of which only
one looks to be non-trivial (http2.FrameType) but even that is a
relatively simple fix.
The Java 7 issues look solvable. That there are *lots* of other API
changes and that is likely to be more significant.
> c) Give up on 8.x and instead release 9 as beta, then stable, with an
> explicit exception about the Servlet 4 API additions being "preview" until
> further notice. That's probably the solution which involves the least
> effort by far.
I assume you mean give up on 8.next and continue to maintain 8.0.x.
> d) Nothing. No 8.x release. 9 will be released sometimes in 2017 when
> Servlet 4 is released. The main issue is that there's no HTTP/2 support
> until then. The longer we wait, the more a major release will conflict with
> the "intuitive" 9 release cycle in 2017.
I don't see any other options than the ones you propose.
Of those options I prefer option b) at the moment. We should probably
call it 8.5 since the degree of API change is significant - like it was
in 5.0 to 5.5.
After that, I have roughly equal preference for a) or c). a) was what I
originally had in mind but b) has since started to look more attractive.
I don't think d) is a viable option. It leaves the new features in 9.0.x
in alpha for too long.
Regardless of the option we choose, an open question is how long do we
support 8.0 in parallel with 8.next? For 5.0/5.5 it was about 2 months.
I'd be prepared to do release management in parallel for ~6 months.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org