On 11/21/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 11/21/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
> > The people working on Tiles2 are gearing up for some sort of release,
> > maybe even this weekend. But, since we distribute Tiles as a plugin,
> > so we could still mark Core GA and leave the Tiles plugin at beta.
> > Right now, all the plugins, including Tiles2 and Codebehind, are
> > tagged and released along with Core.
> >
>
> Why that? To have the users confused?

Bitter experience.

Struts 1.1 was a long, hard, demoralizing trek because we had to have
each and every component "just right" in order to have a release.
Life's too short to live through that kind of frustration again.

Right now, we already have eleven plugins. If each and every one of
those have to be GA in order for the Core to be GA, then, once again,
it will be years between GA release.

I'd rather that the general public were confused but had GA releases,
then have everyone wait years for the next GA release.

The alternative would be to strongly separate the plugins from the
core, as Maven does, but I don't relish having eleven more artifacts
to release.


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".

./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]

Reply via email to