Remy Maucherat wrote:
If it's just to be used for build tools, then it's ok (and no need for a proposal, it just needs to get done). The trouble starts if users start thinking they can use that to upgrade to a newer release, just by upgrading one or two JARs (or ever worse, mixing components). Then there's trouble.
Mixing components may be bad - since it is not tested or supported.
However upgrading only and individual component may be very good in the future. Why do you think that "patch releases" ( where only few individual .jars are updated ) are bad ?
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.
As long as we test the new jar against the stable version - and _we_ recommend the components that should be mixed - I think it is far better way to upgrade.
This is too complex, and not practical. We already have problems with regressions in stable releases, people not testing anything, etc, even with the current system. What you propose would just make things worse.
I don't like your ideas today ;-) Wait until tomorrow to submit them :)
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
