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]