Yeah, sorry, that is what I was trying to say - I'm fine with freezing the API here, pushing future improvements into 2.1 or 3.0. I think we are 100% on the same page here :)

Let's get this puppy rolled!

Don

Ted Husted wrote:
Well, we wouldn't want to *break* the API in the same release series,
since that's what a release series is suppose to mean. If we want to
break the API, we should go onto the next series (2.1 or 3.0). Though,
if we were to break the API, we'd also break WW2 compatibility, and
that's suppose to be the hallmark of this release series.

Even if 2.0.1 core earned GA, we  could still do the "new API" later
in the 2.0.x series, and then move to it completely in the next
series.

Now, I'm not sure that all the plugins are ready for GA. But, the core
seems solid.

-Ted.

On 10/6/06, Don Brown <[EMAIL PROTECTED]> wrote:
Hmm...could Struts 2.0.1 go GA...I hadn't really thought about it
before.  For me, the main thing that GA does is mean that you can't
screw with the API anymore in that branch.  Therefore, if we needed to
do anything significant, we'd have to do it in a new branch, and put the
old API through the deprecation cycle.

That said, I can't think of anything major that I'd want to do to the
API at this point.  I'd love to put this project out to a wider audience
since as you said, it is based on the stable WebWork 2.2.x releases.  I
think I'd be willing to vote GA on Struts 2.0.1.  Of course that means
I'll be working my butt off ensuring the API is documented and website
up to date tomorrow... :)

Don

Ted Husted wrote:
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >> >> On 10/6/06, Ted Husted <[EMAIL PROTECTED]> 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: [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]
>>
>>
>
>


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