Permalink to this page: https://cwiki.apache.org/confluence/x/CjElBg

Table of Contents

Overview

This page provides a high-level view of each of the past, current and planned major Tomcat versions.

The way Apache is structured and governed it is impossible to say that there will be no further enhancements, bug fixes or releases for a given version. Therefore, rather than use "No" in the tables below "Highly unlikely" has been used. That said, highly unlikely means exactly that and users of versions that are highly unlikely to see another release, even for security fixes, should consider moving to a later version.

It is anticipated that releases will be provided for a maximum of 3 major versions at any one time.

The "Process" field in the following tables documents what development model is accepted by that project, either Review-Then-Commit or Commit-Then-Review. For RTC model the changes are first proposed in the STATUS.txt file in the root of the project and have to gain at least 3 "+1" votes before being applied. The project members have agreed on several exceptions from the RTC rule (documented below).

Tomcat 11.0.x

Tomcat 10.1.x

Tomcat 10.0.x

Draft

Need to resolve TBDs. Specifically:

• Do we want to continue to provide support (currently only security fixes) for 3.3.x?
  • markt: Suggest we drop all support for 3.x
• If yes, who is release manager for 3.3.x?
• If no, do we want to remove 3.3.x from the main download page?
  • markt: Yes, if it is agreed to drop support for it
• What level of support do we want to provide for 5.5.x?
  • markt: Bug fixes and security fixes, no enhancements
• Once we have a stable release of 6.2.x, what support do we want to provide for 6.0.x?
  • markt: None. The API change is likely to be minor and impact zero to very few users. If it is an issue then we can change our minds and limit it to just security fixes.
• What features/API changes do we want to include in 6.2.x
  • remm: It could be limited to the AnnotationProcessor -> InstanceManager replacement, and have the branch simply take over for 6.0.x immediately. This also allows placing 6.0.x in security fixes mode since 6.2 is a trivial upgrade path.
  • markt: I'd go further and not do any updates for 6.0.x
• What features/API changes do we want to put in 6.3.x for future inclusion in 6.4.x and/or 7.0.x?
  • markt: That is what the STATUS file and voting is for
    

Tomcat 3.3.x

...

Tomcat 9.0.x

...

Tomcat 8.5.x

Tomcat 8.0.x

...

Tomcat 7.0.x

Tomcat 6.

...

0.x

Tomcat 5.5.x

Features:

• 6.0.x plus
• Geronimo API changes
• TBD
  

Tomcat 4.1

...

.x

Tomcat 3.3.x

Features:

...

Unsupported versions

The following versions are no longer supported. The source is still available from SVN and both source and binary downloads are available from the archives.

• Tomcat 3.0.x
• Tomcat 3.1.x
• Tomcat 3.2.x
• Tomcat 3.3.x
• Tomcat 4.0.x
• Tomcat 4.1.x
• Tomcat 5.0.x
• Tomcat 5.5.x
• Tomcat 6.0.x
• Tomcat 7.0.x
• Tomcat 8.0.x

RTC Exceptions

The following are exceptions to the Review-Than-Commit rule.

• Changes to the documentation (including Javadoc) are C-T-R.

Via https://tomcat.markmail.org/thread/2fgydrrhn4qjye3r :

• Allow C-T-R for trivial fixes to English messages that are in resource files and those that are inline in the code. This includes typos and rephrasing, but does not include adding/removing message parameters.
• Allow C-T-R for any fixes for non-English resource files. The files must use 7-bit characters only. Other symbols must be escaped with \u, as does native2ascii.
• Require some indication in the commit message for code that usually is covered by RTC, that this commit was done using C-T-R rule.

Via https://tomcat.markmail.org/thread/vwqvurietvliadjf :

• The versions that were moved to the archive are C-T-R.