On Thu, Feb 13, 2025 at 10:36 AM Mark Thomas <ma...@apache.org> wrote:
> I haven't seen any further discussion so I am going to draft an > announcement for review that I'll post this list. > Thanks for doing this! I somehow missed the thread before, but I'm +1 for the current plan of action. > Mark > > > > On 04/02/2025 21:14, Christopher Schultz wrote: > > Mark, > > > > On 2/3/25 11:00 AM, Mark Thomas wrote: > >> Responding to all the threads here... > >> > >> On 03/02/2025 13:40, Christopher Schultz wrote: > >> > >> <snip/> > >> > >>>> 3. What minimum version of Java do we want to support? Stick with > >>>> Java 8? Increase the minimum version in line with availability of > >>>> free supported JREs (e.g. from Temurin)? Something else? > >>> > >>> There are some shops who are petrified to change *anything* including > >>> the JVM running their old servlet containers. Sure, some minor things > >>> have changed within the JVM itself but really things should mostly > >>> work with Java 24 that were working in Java 8. The biggest headache > >>> I've seen has been adding --adds-opens and things like that to keep > >>> things working. > >> > >> Consensus appears to be that we continue supporting Tomcat 9 on Java 8. > >> > >>>> 5. Do we effectively just continue with 9.0.x or create 9.?.x? > >>> > >>> My first question would be "what guarantees have we made for Tomcat > >>> 9.0.x that we might want to adjust, requiring a 9.1.x or similar?" I > >>> know some of these "guarantees" might actually be more traditions and > >>> not policies, but I would guess that downstream users have come to > >>> expect certain things from this project, and I believe we should > >>> continue to honor those traditions. > >> > >> If seems that there might be support for dropping support for the APR/ > >> Native connector. > >> > >>>> 6. Do we continue from 9.0.x or do we start from 10.1.x and revert > >>>> the Jakarta EE API changes? > >>> > >>> I don't think I can make a useful contribution this decision. > >>> > >>>> I suspect the folks that want extended 9.0.x support also want > >>>> minimal changes. If we do plan on changing things (minimum Java > >>>> version, dropping APR) we should provide plenty of notice. > >>> > >>> The two available migration tools (Tomcat and Eclipse) are quite > >>> good, though I haven't used them extensively. The fact that you > >>> should be able to deploy a JavaEE web application into Tomcat 10 or > >>> later should be the preferred upgrade path for anyone who doesn't > >>> want to actually port their application. > >>> > >>> I would consider it a bug if Tomcat's migration tool wouldn't allow > >>> an application to be deployed into Tomcat 10+ and continue to work, > >>> barring any API incompatibilities. Such incompatibilities are > >>> currently minimal but will grow over time. Fortunately, search-and- > >>> replace on a code base should effectively perform the same duty on > >>> source that Tomcat performs on binaries. Is there any reason the > >>> Tomcat Migration Tool couldn't be used on *source* artifacts? > >> > >> None. It should work. Converting *.java files is explicitly supported. > >> > >>>> When do we think extended support will start? My best guess is no > >>>> earlier than 31 March 2027. > >>> > >>> This will mostly be tied to the next Jakarta EE release / Tomcat 12, > >>> right? > >> > >> Yes. > >> > >> In summary, I think there is consensus for: > >> > >> - continue Tomcat 9 releases on the same basis as we do currently > >> - continue with Java 8 as the minimum Java version > >> - announce our plans once we think we have something concrete > > > > +3 > > > >> And potentially (separating this out so folks can object) > >> > >> - Deprecate the APR/Native connector and advertise it will be removed in > >> 9.1.x onwards > > > > +1 > > > >> - EOL 9.0.x no earlier than 31 March 2027 (based on Jakarta EE 12 > >> release dates) > > > > +1 > > > >> - Provide LTS via 9.1.x which is 9.0.x less the APr/Native connector > >> with those components modified to be NO-OPs / log a warning / > >> automatically use NIO+OpenSSL instead as appropriate > > > > +1 > > > >> If we can finalise this as a plan in the next few weeks that allows us > >> to get a notice out by 31 March this year providing at least 2 years > >> notice of 9.0.x's EOL and the plans for 9.1.x. > > > > +1 ! > > > > -chris > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >