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]
