Mark,
On 5/12/26 11:45 AM, Mark Thomas wrote:
All,
The Jakarta EE project is aiming to align Jakarta EE releases with Java
LTS releases. That would mean a Jakarta EE release every 2 years which
in turn would mean a Tomcat release every 2 years.
If we stuck to our "support the 3 latest major versions" (ignoring 9.0.x
as a special case) then that would mean the typical support period for a
major Tomcat release dropping from ~10 years to ~6 years.
What, if anything, do we want to do about that?
I'll note that the last Servlet API release was May 2024 and, while we
are in May 2026, discussions on the timing of the Jakarta EE 12 release
train haven't started (or at least haven't reached me as project
manager) yet.
Wait and see seems like the most sensible option at the moment but I
wanted to raise awareness so we could start thinking about possible
options should we need to make some changes.
+1 to wait and see.
My guess is that if Jakarta EE aligns to the Java LTS schedule, each
Jakarta EE version change is going to be much smaller in scope then in
the past. We may not actually need to have separate versions for each
Jakarta EE release, though it would torpedo our whole "Tomcat version
number matches Jakarta EE version number" scheme.
Maybe we could talk to the Tomcat community about how important certain
version changes actually are. Obviously, the change from Java EE ->
Jakarta EE is a huge change. But does anyone remember switching from
Servlet 2.1 -> 2.2? Did anyone's applications stop working? Probably
not. How about 2.3 -> 3.0? 3.1? I spent a ton of time slowly migrating
from Tomcat 4.something to Tomcat 7.something "just in case" and there
was nothing at all to be worried about. I wasn't using any of those
weird edge cases that were negatively affected by any of those upgrades.
If Jakarta EE 14 adds a few new things, it shouldn't bother most
applications already running on Jakarta EE 13 or whatever. If that's
true, then maybe we don't need to be providing 10-year support anymore
for every version.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
