On Feb 9, 2004, at 11:36 PM, Patrick Lightbody wrote:
Hey no worries, it's all part of the fun. Water under the bridge, blahblah. I'll sure we'll yell at one another again in a few weeks anyway.I want to apologize for my last email. I was over the line and made implications and statements I should not have. I let what I perceive as "threats" to a project I have devoted a large part of my life over the last year take better hold of my judgment. I am sorry to Hani and to everyone on this list.
* I want 1.4 to continue to exist and be maintained and provide supportYep.
for anyone using 1.x for as long as they feel comfortable.
* This statement from Hani points out my only concern:Well, I'll clarify. the 1.x branch will never become 2.x, in the sense that it won't backport everything until there's no difference. That'd be rather silly. In some (few) cases, there are features present in 2.0 that would be very very useful to have in 1.4. These would be low impact additions that would fit in with the existing (admittedly somewhat hobbled) architecture of 1.4. For example, the implementing of some of the OGNL features into the 1.4 parser (Dick mentioned string concatenation for one).
1.xWell, we're not ruling out major new features (perhaps even borrowing from 2.0 if there's enough demand for it). The goal is different from 2.0 though, which is why both branches are alive and well. Think ofusers as conservative old-fashioned people, who aren't huge fans of change, and are much happier without having to spend a lot of time sending emails to find out why feature X changed, etc etc.
If 1.4 is supposed to not be about change, then why borrow from 2.0 and introduce change? My one and only fear is that if a roadmap can't be established, then more confusion like Wayland's will continue to crop up.
Another example is the spring integration, to provide an option for 1.4 users to use some form of interceptors (alongside the other goodies spring provides).
We've agreed on this in the past. Nothing new here.I merely want to make sure that Hani and Dick commit to coordinating with the 2.0 team (for compatibility), which will ultimately provide a more clear picture about the two versions.
I apologize for exposing the list to a potential flame fest (we haven'tI dunno, I think it's pretty clear to most users. 1.4 is the old version of webwork. It has an established user base with many high impact production deployments. It is a mature product that is maintained, but it is unlikely to change (grow) much. Webwork 2.0 is the next step from that, with new features and enhancements and is a lot more cutting edge.
had one in over a year!) and I especially apologize to Hani for not
thinking before typing. I hope that this better explains my concerns and
that we might come to an agreement that doesn't make WebWork appear to
have an identity crisis.
Which should users go with? Well, it's up to them. I'd currently recommend 1.4, since I personally feel it's a lot more tested and deployed at far more places. You don't need to be a mailing list subscriber to use it, and many eyeballs have been over the code. Many (most) people on this list disagree, they're comfortable and pleased with 2.0, and feel more of a sense of progress there, good for them.
What I won't do is paint 1.4 in an inferior light. I don't think I'm alone either in saying that the argument that at this moment it's a more robust product is at least debatable, and not to be dismissed out of hand.
Anyway, time to move on.
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
