May I kindly recommend how unclear this version naming scheme appears to even the Struts committers? I cannot think of any other open source project that is trying to divide sub-projects into different versions, which is, not to be confusing, not the same as the version number of the packaged release.
Take a look at the Spring framework. They release both the full spring.jar as well as spring-aop, spring-dao, spring-mvc, etc. The full and miniature libaries are released under ONE version number. There will be a Spring 1.2.7 coming out, which means updates to any of those libaries all together -- not 1.2.4 for this library, 1.2.3 for here, 1.2.7 for here and then together = 1.2.7. Honestly, I never thought the versioning scheme you guys are now attempting now is very intuitive. Please don't confuse my criticality with being mean. I want you guys to succeed, but this innovative versioning scheme is really a mental-draining loser in the long run, imo. I know you guys want to release as "1.3.0" first and then have the libary versions go the separate ways, but this is sure to muck you the moment you have to update libraries in tandem. If new feature X in the tag library requires new feature Y in the core, you guys have destroyed the whole independence you saught with separate releases. I say take the Spring model: same version number for ALL libraries, full or miniature, and release the full set each time as ONE version number. Just my 2 cents. Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
