tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin <>
Subject Re: Frequency of Tomcat Native releases
Date Sat, 03 Oct 2015 22:51:19 GMT
> - ensure the changelog is up to date
Looks like r1681506 could be logged.
> - versions all correct in source
$ find . -type f -exec grep '-H' '1\.1\.' '{}' \;...
./1.1.x/xdocs/index.xml:...<b>TC-Native-1.1.33 released</b></a>
./1.1.x/xdocs/index.xml:... availability of Tomcat Native 1.1.33 Stable.
./1.1.x/xdocs/news/2015.xml:... TC-Native-1.1.33 released">

> - select and document APR & OpenSSL versions
Please update APR from 1.5.1 to 1.5.2. Please update OpenSSL from 1.0.1m to 1.0.2d.

> - check everything builds correctly
You'd get more volunteers if building APR didn't require MSVC 6.0 or however you build .dsw.
In fact, it'd be nice to see many of these projects adopt Gradle and do away with many of
these old build tools. I tried to build Tomcat Native once from repository and found my version
of Python was too new. Gradle allows the flexibility of MSVC, GCC, clang.


     On Friday, October 2, 2015 5:15 PM, Mark Thomas <> wrote:

 On 02/10/2015 19:01, Justin wrote:
> Can we see more frequent releases of Tomcat Native, especially since
> it statically links OpenSSL on Windows? I was hoping to see a new
> release included in Tomcat 8.0.27. There have been a number of
> changes to both Tomcat Native 1.1.x and OpenSSL 1.0.2. 

I've done the last few tc-native releases because they reached the point
where they really needed to happen. tc-native isn't my area of expertise
so I'd be more than happy to see someone else take this on.

More frequent releases are certainly possible and very much the way we
should be aiming to do things as an Apache project. "Release early and
release often" is the goal.

What contribution are you (or anyone else reading this) willing/able to
make to help this process along?

The tc-native release process is documented (ish) here:


Off the top of my head things that need to be done / checked:

- ensure the changelog is up to date
- versions all correct in source
- select and document APR & OpenSSL versions
- check everything builds correctly

Confirmation that any of the above is ready to go or patches to fix
things if there are gaps will move a release forward.

I can find the time to apply patches and turn the handle on the release
if others can do the work to ensure that svn is in a good state to release.

It is a fairly safe bet that anyone helping out substantially on the
release is going to find themselves with an invitation to become a
Tomcat committer and the RM for the next release.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message