Remy Maucherat wrote:
For example if we fix something in jk - should we have to make a full new release of tomcat ? Same for jasper, catalina, etc.
Yes, we do. We release stable builds based on multiple components. We can't support pick and choosing (latest big example: Xerces, which you couldn't upgrade to the latest release). That's a guarantee to users that we have tested that particular combination. How we handle the thing internally is irrelevant, we have to present users with a single archive containing everything needed.
It's not about "pick and choose" - we control the list that makes up a
stable release.
I think we're looking at this problem from very different angles.
I won't use xerces as an example ( it's a trap :-), but commons-logging If some bugs are fixed (that affect tomcat) - we can recommend people to update commons-logging to the specific version that we tested and includes the fixes.
If we find a bug in jasper - we can test the fix against the "stable"
release and make a mini-release with only jasper.
At any givent time, "Tomcat stable" will be the latest major release (
4.1.24 ) plus any additional patches that we test. All OS vendors have
"patches" that include updates to individual components ( well, Microsoft
has the huge service packs, but most other just update very specific
components ).
Most of our components are relatively independent of each other and we have reasonably stable APIs, so "pick and choose on your own" could work,
but we can't support it.
To follow a Packaged approach, ie using rpm/deb, tc5/tc4.1 should have its own jars and dependencies on externals jar (logging, mx4j.).
With this way it's easy to maintain a tomcat version with up to date externals jars (assuming they are backward compatible).
But that's just my 'packager' vision...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
