On 3/20/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > I do see benefit in having the struts-taglibs (and actions) being their > own release because there are some very minor enhancements > that don't really require a new action framework release. > For instance, Struts 1.2.5 added the errorStyle and errorStyleClass > attributes, which probably could have been released faster > if they were separate. This is the same situation for the struts-actions > library which doesn't need a framework upgrade to add new functionality. > > However, the biggest downside of separate releases, as I see it, > will be the confusion in the separate versioning of the libraries. > Someone might be asking one day, "Does taglibs-1.3.11 go with > struts-action-1.3.4 or struts-action-1.3.6?" It is really going to > be difficult to eyeball which version library depends on which version > library of another. Did I get this wrong? Isn't this how the independent > libraies will be released at different schedules?
compatibility is not that difficult to maintain in reality. for project developers there are just 3 simple rules to follow: - no point release (1.3.1 to 1.3.2) should ever break a working, outward facing API - all minor versions (1.3.x to 1.4.x) should deprecate working, outward facing APIs before removing (release foo in 1.3.x, deprecate in 1.4.x, and remove no sooner than 1.5.x, if at all). - all major versions (1.x.x to 2.x.x) are free to break or change whatever they wish. assuming developers respect these well-established patterns, then users worried about compatibility and dependencies and unwilling to track all project changes, there are only three simple rules: - point release versions that go GA are always safe to upgrade - watch for deprecations when upgrading minor version numbers - expect things to break with a major version upgrade and all of that can be done without any documentation apart from the version numbers themselves. throw in notice of deprecations in changelogs, and simple instructions about the latest versions (struts-taglibs 1.6.x depends on struts-action-core 1.4.x) and what's the big deal? also, by separating out the various "extra" components, you make the development and maintenance of entirely new components (e.g. VelocityStruts) easier, because some former "internal" APIs are now the "external" APIs of the core compenents. since those are now outward facing, compatibility and stability of the core is more rigorously maintained. so for those not under the Struts umbrella, life becomes better. :) > If so, an alternative would be to re-tag all libraries and release > them under one distribution version. If struts-taglibs go through > 5 quick releases, that's also 5 quick releases of Struts too. heh. who ever heard of a quick Struts release? now you're just talking nonsense. ;-) but seriously, this is totally unrealistic. the different projects will overlap in their various states of readiness/buginess and the next GA release of any of it must wait until all of it is ready. > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
