Alexandru Popescu wrote:
I am not gonna argue against your argument but just say: the user will
be confused when he will not be able to run the plugins because a
small change in one of them has broken it. The release should be able
to guarantee a set of plugins that work out of the box. The user
should not have to deal with different projects, different lifecycles,
etc and finally figure out that we must use beta-xyz of plugin X
instead of beta-xxz of the same plugin. This would be synonim to
saying: "hey, we have tried our release with something that worked for
us, but we cannot guarantee what will work for you".
I agree completely. That's why Struts plugins use the same lifecycle,
project, and version number as Struts 2 core. The difference is we will
include in the release notes comments about the quality or confidence of
each plugin. If you can think of a better way to handle it, let's hear
it. :)
Don
./alex
--
.w( the_mindstorm )p.
> That was a good decission whoever took it.
AFAIK, importing the Guice code into XWork2 was Don's idea, and I
would agree.
> Building is one... having time to play with it is another. A
> successful build doesn't guarantee anything in fact.
Exactly. When it comes to a release, it's the PMC's to do more than
make sure the code builds. It's our job to warrant that the bits work
well, based on our own direct experience. As the saying goes, "We eat
our own dog food," and then we pass the bowl. :)
-Ted.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
