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
