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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
