At 03:48 AM 4/5/2004, Ted Husted wrote:
On Sun, 04 Apr 2004 23:37:22 -0400, Robert Leland wrote: > It may be that a full blown Jerico would be struts 3.0, but we have > to start somewhere.
How about this:
In 1.2.x, we've been removing the deprecations and adding some API niceties, like wildcard mappings and the "module" tag attributes.
In 1.3.x, we were going to start doing more aggressive things, like bring the Struts-Chain RequestProcessor into the Core and finish the move to Maven.
Coincidentally, we are migrating to a TLP (kudos to Martin for all his hard work!), and it's likely that 1.3.x will be our first "struts.apache.org" release series. We might also have subprojects then, so there would be coinciding releases of taglibs-classic, taglibs-jstl and taglibs-faces.
So why not just label want we were going to do in 1.3.x as Struts 2.x, and start calling Jericho (or whatever else we do -- it's just a whiteboard) 3.x ?
Struts 1.x then remains Servlet 2.2, JSP 1.1, Java 1.2.
Struts 2.x (fka 1.3.x) can then be Servlet 2.3, JSP 1.2, and Java 1.3.
Struts 3.x (fka 2.x) can then be Servlet 2.4 and JSP 2.0, as planned.
There will be some short-term confusion among some developers, since we've been saying that 2.x would be the revolution and this change means that 3.x would then be the revolution (if we don't refactor our way there first!). But, I think we can live with that issue if changing release numbers solves other problems. [I guess this circumstance is why so many teams like to use names rather than numbers :)]
> I have been thinking this for a long time. Folks will still have > the 1.2.X release series. > > It may be possible for 1.3 struts to remain backwards compatable, > but to start experimenting with servlet 2.3 features.
Agreed.
>From an API perspective, simply moving to servlet 2.3 will not create any backward-compatibility issues. The issues are infrastructure and deployment compatibility. IMHO, when we talk about backward-compatibility, we are referring mainly to the API. If they can run the same Struts config, Actions, and JSPs unchanged, under whatever platform, then it's backward compatible. What spec level we use is just a refection of what our community is using.
A year ago, I still knew people in major corporations who were on 2.2, but were looking forward to upgrading to 2.3 in the short term. Another year has passed, and I think we should stop living in the past and start exploiting the spec our community is using. If we start using filters and listeners ourselves, then that will encourage other people to do the same. A lot of people need to do Struts-like things with their business objects, that they should be doing with filters and listeners, and we can starting showing them how. As
> I believe we should start moving forward. Perhaps we can adopt > Bugzilla's and Linux scheme > of even/odd build numbers. Even is stable production releases and > odd is development builds. The development > builds would give us CVS space to start experimenting with whats > been on paper. If we find out that > making Struts 1.4 (The stable release) backward compatable based on > what is learned with Struts 1.3 development build > then we scratch 1.4 and go right to 2.0 (which is by the way an > even build number)
I'd lean toward sticking with the HTTPD/Tomcat approach for now.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
