On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote: > > By modules/ I mean mostly release units - so maybe a build.xml to create > build and package the module, some readme, manifest, etc. Tomcat normal > release wouldn't include the module, but it can be released independently, > maybe > for multiple versions of tomcat. > Look, if someone is willing to break the build it will do it no mater what. Like said, having multiple builds is fine with me, but having multiple builds just for the sake of some broken module is not. If the module is part of the Tomcat, then there can be no release if its build fails. It is just the same as for the Httpd etc.
This is not an issue of 'broken build', it's an issue of release units and lifecycle. A module release cycle should not block the release of tomcat - it's just an optional add-on that has it's own life and version number. Also, I see no purpose of backporting the modules separately
to the previous versions. If we have a product, then we can either provide the patch to the previous version as a whole, or simply say to the people to use the current stable version. If the patch will only relate to the module A, then it will be treated as a patch to the Tomcat6.x.y no to the module A for the Tomcat6.x.y. IMHO that'll be less confusing to the end users.
Ok. That's a separate issue as well, sorry for mixing it up. What I would like is for tomcat6 release to not include all possible features. Maybe for backward compatibility we need to include all that tomcat5 includes, maybe we can move out some large ones or things that are still refactored ( like cluster support ). I don't see the benefit of having things like cluster support in the tomcat release - if someone does want a cluster, they can easily download an additional jar - setting up a cluster involves a lot of work, we won't make it much simpler by bundling the jar with tomcat. Costin
