I think that's a realistic goal. I'm all for starting with a
manageable subset of features in the first release and incrementally
introducing more features in a backward compatible way in followup
releases.

Bob

On 4/24/06, Don Brown <[EMAIL PROTECTED]> wrote:
> If we can get this "clean API" in by July, then I'm fine with it being in SAF 
> 2.  The bottom line is I think we need a
> GA release by August, but it is important to remember a lot more goes into a 
> release than just coding - build processes,
> release processes, documentation, testing, etc.  This type of stuff is hard 
> to get folks to sign up for, so it usually
> ends up dragging on.  Unfortunately, releases aren't as simple as a code 
> snapshot :/
>
> I think realistically we'll be sifting through the rough spots document, 
> picking some and discarding others, then
> implementing them in a staggered fashion.  Introducing a strong annotation 
> support in 2.1, for example, is a more
> realistic goal, than trying to quickly get it down and push it in for the 
> August release.
>
> Don
>
> Bob Lee wrote:
> > I'm not sure two major releases is what's best for users.
> >
> > - If SAF2 is going to be the same as WW2, why have it at all? I think
> > it will confuse users unnecessarily.
> > - We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and 
> > SAF2.
> > - Some users will migrate to SAF2 and then will have to migrate again to 
> > SAF3.
> > - People will think we're incompetent and disorganized and that we
> > care more about playing than supporting users based on the fact that
> > we completely redesigned our framework twice in such a short period of
> > time (SAF1 -> SAF2 -> SAF3).
> >
> > I think we're overestimating the amount of effort it will take to do
> > this right. Designing a clean API that we can support for the next 5
> > years should be our #1 priority. We can do a minimal amount of work on
> > the implementation so we can release ASAP and clean it up later.
> >
> > Bob
> >
> > On 4/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> >> On the RoughSpots page,
> >>
> >> * http://wiki.apache.org/struts/RoughSpots
> >>
> >> there's a reference to Action 3.x that speaks as if it's far away.
> >> That doesn't need to be the case. We can create a branch for "Action
> >> Next" or "Ti2" as soon as the code comes down from the incubator. We
> >> did the same for Action 1.2 and Action 1.3. We've continued to
> >> maintain and extend Action 1.2, while more agressive changes where
> >> made to Action 1.3.
> >>
> >> The original proposal was for Ti to happen in two phases. The first
> >> phase was to release Action 2.0 based on WebWork 2.2 by making only
> >> necessary and prudent changes. More aggressive changes were to happen
> >> in Ti Phase 2. Many of the "Rough Spots" may be Phase 2 changes. Phase
> >> 2 might be Action 2.1 or Action 3.x. That's a decision we can make
> >> later.
> >>
> >> Personally, I don't believe the release of Action 2.0 is going to
> >> create a migration stampede. Some people who are starting new projects
> >> may decide to use Action 2 instead of Action 1. But the people I know
> >> won't bother to migrate existing applications. At least not anytime
> >> soon.
> >>
> >> Right now, some teams that are looking forward to Action 2 are getting
> >> started with WebWork 2.2 now. I suggest that Job One should be to get
> >> a current release out there that we can use while we work on Phase 2.
> >> Otherwise, we could easily find ourself maintaining WebWork 2.x at
> >> OpenSymphony and then having to mirror any changes in Action 2.x at
> >> Apache Struts.
> >>
> >> I think it's important to first create a stable release of Action 2.0
> >> as the direct successor to WebWork 2.2, and then focus on the more
> >> aggressive changes slated for Phase 2. We can make it very clear to
> >> people that "Phase 2" is in the works, so people who don't want to
> >> migrate more than once can make an informed decision.
> >>
> >> Thoughts?
> >>
> >> -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]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to