struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <hus...@apache.org>
Subject Re: Struts 2.0.1 release
Date Fri, 06 Oct 2006 22:26:53 GMT
Has anyone volunteered to work on the XWork docs?

The XW2 docs aren't any better or worse than the XW 1.1 docs, and I
believe that release series was getting the "ready for prime time"
stamp.

Is anyone besides Struts 2.0.x trying to use XWork in production? Is
there even an XWork forum any more?

Aside from the Tiles plugin, which we could sidestep, there might not
be anything else that would keep Struts 2.0.1 from going GA. There's
other stuff we want to do, but what we've done is solid, useful, and
complete. (Which given the starting point, shouldn't be suprising!)

I mean, if we find issues as more people use Struts 2.0.1, then sure
we reflect that status in the quality grade. But why make a beta
status a foregone conclusion?

-Ted.


On 10/6/06, Don Brown <mrdon@twdata.org> wrote:
> XWork does use the alpha, beta, stable tagging of releases, however, the
> release process is lightweight and many people have commit access.  I
> do, and you just need to ask Patrick to get access yourself.  To be
> honest, this XWork release shouldn't go 2.0.0 final, because the
> documentation for XWork is woefully out of date and needs work.  Also,
> I'd like to test all the new changes we made for a beta release or two
> before we slap that label on it.
>
> Don
>
> Ted Husted wrote:
> > Yes.
> >
> > Though, does XWork the release process allow for updating the bits
> > from beta to stable or GA?
> >
> > The reason I ask is that our 2.0.1 release will be tied to whatever
> > version moniker that XWork uses. If tomorrow's XWork release is tagged
> > as "beta", and that cannot change for that set of bits, then the 2.0.1
> > release will also be forever beta.
> >
> > OTOH, if XWork were tagged as a 2.0.0 release, and it were upgradable
> > from beta to stable/GA at a later date, then we would be able to do
> > the same with Struts 2.0.1 (should it merit the quality upgrade).
> >
> > Otherwise, we will always be playing hand-over-hand with XWork. After
> > XWork generates a GA/Stable release, we will have to rebuild and
> > redistribute a Struts build all over again. Avoiding "cascading
> > release triggers" is a key benefit of the build-then-grade-and-upgrade
> > approach. If a build has dependencies that are upgraded, we don't have
> > to redistribute the bits, just upgrade our quality assessment.
> >
> > -Ted.
> >
> > On 10/6/06, Rainer Hermanns <hermanns@aixcept.de> wrote:
> >> Ted,
> >> I am planning a beta-1 release of xwork 2.0 for tomorrow.
> >> This will be tagged and build with a fixed version number.
> >>
> >> Would this fit into your timeframe?
> >>
> >> Rainer
> >>
> >> > I don't have karma to XWork, so it's not something I could tag myself.
> >> >
> >> > -Ted.
> >> >
> >> > On 10/6/06, Wendy Smoak <wsmoak@gmail.com> wrote:
> >> >> On 10/6/06, Ted Husted <husted@apache.org> wrote:
> >> >>
> >> >> > I'm wondering if maybe we should roll this tomorrow afternoon
> >> instead.
> >> >> > They might be working on the Internet connection on Monday, and
my
> >> >> > tutorial is Monday afternoon. It would be nice to have it before
I
> >> >> > leave, so that I can put it on the tutorial CDs, and cover the
> >> new S1
> >> >> > compatability bridge classes.
> >> >>
> >> >> This may be on your list already, but XWork needs to be tagged and
> >> >> built at a fixed version number in advance of a Struts 2 build.
> >> >>
> >> >> (The snapshot dependency in the Struts 2.0.0 pom caused problems for
> >> >> Maven users once new XWork snapshots were published.)
> >> >>
> >> >> Thanks,
> >> >> Wendy
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
HTH, Ted.
* http://www.husted.com/struts/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message