I think he has a point in that Tapestry needs a stable release.
Now, all of the major architectural concerns *have* to be addressed, IMO, before we even consider going that kind of long-term stability (the use of abstract classes, the rewind cycle, etc).
By the way, is it possible to split Tapestry's development in tapestry-core and tapestry-components and remove the contrib project? I think Tapestry could benefit of a component base consolidation along with the architectural changes, and those can be done in separate sub-projects, don't you think ??
As for stabilization, I mostly think Tapestry is suffering from some disorganization (growing pains I guess) that could be solved by using JIRA to plan releases an such.
Just my 2 cents.. -- Ing. Leonardo Quijano Vincenzi DTQ Software Cliff Zhao wrote:
IMHO, from a user perspective, to let more users accept Tapestry, Tapestry should consider more for the users. Compatibility and the ease of upgrade should be a high priority. Tapestry should build a kernel that lasts over time. Drastic changes from release to release will drive users away. A large user base and community is very important for an enterprise user. I like Tapestry but as a architect in a big company, I may have to reconsider my choice if Tapestry can not reach a stable stage within six months. Every upgrade is a non-trivial cost for an SEI CMM level 3 organization that is targeting CMMI level 5 certification. For me, it's more important to have a stable, well optimized and well documented Tapestry. Best Regards, Cliff Zhao
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
