Jose,
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
Historically:
- 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.
-chris
On Sun, Mar 13, 2022 at 5:42 PM Mark Thomas <ma...@apache.org> 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.
https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
