Ted Husted wrote:
I'm perfectly willing to backport the bugfixes, and the Struts
documentation is bundled with the release. We'd just have to patch the
release notes pages with any updates.
Unfortunately, I don't believe that is possible, and really, it would be
counter-productive. There as been too many fundamental changes since
then, and backporting the bugs would mean combing through each commit.
As I said before, I don't really understand why we would want to spend
the time turning back the clock, when we could put a few good weeks into
xwork and Struts to get a GA release now.
The XWork trunk does not work with the current release, so we would
have to branch XWork too, and increment its head as well. Given karma
to XWork, I'm perfectly willing to handle that too.
Again, there have been a ton of XWork changes as well, and starting over
the beta-rc-final cycle would take way too long.
Since XWork uses a release candidate system, it's impossible to get a
GA release out without several stepping stone releases. First the
Struts release 2.0.2, which will be hamstrung at beta has to ship with
RC1. If XWork then goes from RC1 to Final, then the Struts release
2.0.3 has to ship to incorporate the XWork final release. Between each
round, we will need to distribute the betas for wider testing before
we go on to vote GA. If for any reason, XWork needs a RC2, then we
won't have a GA candidate until at least Struts 2.0.4.
I'd feel a lot better if XWork would move to the milestone release
that we use, and Tomcat uses, and HTTPD uses, and MySQL uses, to name
a few. This hand-over-hand approach, that continually dooms Struts
releases to beta status is a frustrating waste of volunteer hours.
I don't see how that would help. If XWork put out a release that it
thought was of beta quality, time wouldn't change that. Rainer has a
specific list of things he wants to have accomplished before a final
release, and once they are done, we'll get our XWork 2.0 final.
Again, we are so close to having this thing wrapped up. If splitting
out the ajax tags is too much, it could wait till 2.1. Other than a few
bugs in showcase, we are golden.
Don
-Ted.
On 12/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
It is an interesting idea, but the showstoppers for me are:
* All the bugs that have been fixed since then
* The documentation would be completely wrong as it is for 2.0.2
* XWork trunk might not even work with 2.0.1
I think we are 95% of the way to a GA release and really do think it
could be done in the next few weeks.
Don
Ted Husted wrote:
> On 12/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
>> The change I made to xwork is a very minor, internal Guice
improvement
>> that should have no impact on its GA release. I haven't checked with
>> Rainer lately, but I'd imagine XWork 2.0 could go final very soon.
>>
>> As for branching for 2.1, yeah, we could do that.
>
> Actually, the suggestion is to branch for Struts 2.0.1 and XWork Beta
> 1, to see if we can make them into GA candidates now, as in a week or
> ten days, rather than months from now.
>
> Struts 2.0.1 and XWB1 are being used in production and are being used
> to build production applications. I believe both have met the test of
> "General Availability". We would need to fix or document issues with
> some of the showcase examples, but after a few small patches, the bits
> should be good to go.
>
> Struts 2.0.1 meets the standard of a "WebWork compatability release",
> which was all we wanted to do with Struts 2.0.x. At this point, we've
> come far enough with Struts 2.1 that people can see where we are going
> and adjust their own plans accordingly.
>
>
>> I'm very much interested in a GA release in Jan or Feb, but I do
want to
>> make sure it isn't one we are ashamed of.
>
> Personally, I'm quite proud of Struts 2.0.1. We just need to correct
> the XWork beta moniker.
>
> -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]
