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
>
>

Reply via email to