On 3/14/22 10:55, Jose Illescas wrote:
Thank You for your response and link...

But I disagree with their opinion, because the "jakartization" of packages
it is a very rupturist change:

All libraries, frameworks and applications that run over a j2ee container
(tomcat, jetty, jboss...) must be changed or adapted. For me, this is
enough reason to force a mayor version change)

If you see from a developer point of view:

    - Versión 10.0 (supports Jakarta EE 9) disappeared when Jakarta EE 10
    released (as proposed in your link)
       - I prefer ignore the 10.0.X version (currently is latest and stable
       release of Tomcat) and wait until Tomcat 10.1.X released (support Jakarta
       EE 10).
          - Why I change all my applications to run over 10.0.X (Jakarta EE
          10)? when this versión 10.0.X will die in a "very" near future?
          - forced to me a double change, now, to run over Tomcat-10.0.X
          (Jakarta EE 10) and another change to run over Tomcat- 10.1.X version
          (Jakarta EE 11)

Note that Java 10 will auto-migrate older applications for you without modification. It's kind of a friendly bootstrapping feature to help developers make the transition to pre-Jakarta-EE to port-Jakarta-EE. You're welcome.

I see an forced version alignment between Tomcat and Jakarta EE


    - Tomcat 7.0.x : support Java EE 6
    - Tomcat 8.5.x : support Java EE 7
    - Tomcat 9.0.x : support Java EE 8
    - Tomcat 10.0.x : support Jakarta EE 9 (with my proposal)
    - Tomcat 11.0.x : support Jakarta EE 10 (with my proposal)
    - Tomcat 12.0.x : support Jakarta EE 11 (with my proposal)

     New policy:

    - Tomcat 8.5.x : support Java EE 7
    - Tomcat 9.0.x : support Java EE 8
    - Tomcat 10.0.x : support Jakarta EE 9 (disappears when Jakarta EE 10
    released, developers must be readapt their apps to Jakarta EE 10)
    - Tomcat 10.1.x : support Jakarta EE 10 (confused with 10.0.x version,
    is not the same)
    - Tomcat 11.0.x : support Jakarta EE 11

This is entirely intentional: the version of Tomcat being aligned with the version of Jakarta EE was a somewhat happy accident. Back when servlet versions were the most important, there were 2.1, 2.2, 2.3, 2.4, 2.5, then 3.0 and some of those resulted in different major versions of Apache Tomcat.

As Jakarta EE 9, 10, and 11 are announced, we saw were just one version off and that the transition from Java EE 8 to Jakarta EE was going to be a disaster for everyone.

What better way to help clarify things by adjusting our release numbering slightly so that the numbers match each other? It will be much better down the line.

I think a part of the problem is that you read too much into the actual numbering scheme. When you see 10.0 versus 10.1 you see a minor-feature release while we see a major release. This has happened at least twice before in recent Apache Tomcat memory: Tomcat 5.0 existed and then Tomcat 5.5 was released with major changes. The same is true for Tomcat 8.0 and Tomcat 8.5. In both cases, we didn't go from N -> N+1 but instead N.0 -> N.0+∂. The changes were important enough to make it clear the versions weren't compatible with each other, but it didn't make sense to use a new whole version number. (In both cases, I believe Tomcat N+1 had either already been defined, or in fact already been /released/.)

So we're sorry if our decisions about the version numbering scheme are disturbing you. But the transition from Java EE to Jakarta EE is going to be a big mess and the version-numbering for Tomcat is the last of anyone's problems. Aligning to the Jakarta EE version will help everybody moving forward, so that's what we've chosen to do.


On Sun, Mar 13, 2022 at 5:42 PM Mark Thomas <> wrote:

On 13/03/2022 13:29, Jose Illescas wrote:
I think that Tomcat mayor version must be change when updateing some of
their specs (servlet/jsp7/websockets/...)

This strategy allow us to refer to tomcat with: Tomcat-9 or Tomcat-10
avoiding annoying names as tomcat-10.0.X or tomcat-10.1.X

      IMHO I think that Tomcat 10.1.X version must be renamed to 11.X

The community disagrees with your humble opinion.

The plans for 9.10.x have evolved. Largely because the Tomcat API hasn't
changed much between 9.0.x and 10.0.x/10.1.x.

There is a commitment that there will be a Tomcat version that supports
the Java EE 8 API (part from the minimum Java version requirement) for
as long as there is a demand for it. Exactly what that ends up looking
like is TBD. My current best guess is around the time 9.0.x reaches EOL
we'll introduce 9.10.x that backports of lot of the changes in the
10.1.x branch. When 10.1.x reaches EOL we'll introduce 9.11.x etc.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to