Remy Maucherat wrote:
Petr Jiricka wrote:
- Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model.
I do manage to integrate patches in the JBoss tree without the need for a stable release, whenever I really need a particular fix.
IMO, you should be prepared to do the same once in a while, it's easier for everyone. I believe Tomcat is used in a number of high profile servers (in addition to your usage), so making a release each time someone needs something (I suppose in the few days before a freeze of the relevant products, it would probably be every 5 minutes ;) ) isn't possible.
The advantage of stable releases is that these are much more thoroughly tested by the community than ad-hoc builds. Also, a stable release is a way of saying to the community that "we believe that what we have now works together, it is safe to use the fixes that have come in". We should not be asking "why to do a release" - let's ask "why not?". We could easily do a custom build with just the bugfixes we need, but I think the community would benefit if the fixes are exposed in a public release.
As for the other part of your question - yes, our main motivation for a new release is to use it in our product, but we are not talking about "days". In fact, we have been testing NetBeans with Tomcat 5 since January, and submitted a fair number of bug reports since then. I believe monthly releases are reasonable - we are definitely not talking about a release every 5 minutes :)
- The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor.
- The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.)
This is disruptive for 5.0.x. So, sorry, but I vote no for that one.
My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?).
Ok, we have a different opinion here, see my reply to Yoav.
- Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered.
This makes sense, but you need to indicate which patches need to be backported. I expect it's the JSP debugging related fixes then ?
Yes, we'd like to see the JSP debugging bugfixes in, but I am not only talking about bugfixes requested by Sun. If the community feels strongly that a particular bugfix should be ported to 5.0.x, then it can be done. This should be a community effort, not a "Sun release".
From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase.
Nice plan :)
(ok, actually, we did that already before starting the refactoring, as Yoav mentioned)
Thanks again.
Petr
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
