RE: Rename version 10.1 to 11
Chris, and the rest of the TC team cs> Note that Java 10 will auto-migrate older applications for you cs> without modification. It's kind of a friendly bootstrapping feature cs> to help developers make the transition to pre-Jakarta-EE to cs> port-Jakarta-EE. Thaaanks! :-) cs> the transition from Java EE to Jakarta EE is going to be a big mess cs> and the version-numbering for Tomcat is the last of anyone's cs> problems. Aligning to the Jakarta EE version will help everybody cs> moving forward, so that's what we've chosen to do. +1 To quote Patrick Star, "Sounds reasonable." -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rename version 10.1 to 11
Thank you very much, for your response and time... With time, I will see as normal the new versions -jose On Mon, Mar 14, 2022 at 5:36 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > 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 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
RE: Rename version 10.1 to 11
> Christopher Schultz wrote: > So we're sorry if our decisions about the version numbering scheme are > disturbing you. Just to add another data point: I don’t care about the numbering scheme as long as the code does what I need it to do. Tomcat works for me and does it very well. I have to believe there are many other users that feel the same way. Tomcat is a great product with amazing support from *volunteers* who choose to spend them time helping others. Thank you to all for that. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rename version 10.1 to 11
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 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 additi
Re: Rename version 10.1 to 11
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) 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 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. > > > 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 > >
Re: Rename version 10.1 to 11
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
