On 3/20/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > 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
One of the problems is when a point release change in one package relies on a specific point release change in another package. If struts-action-1.3.2 adds some new functionality, and struts-taglib-1.3.1 uses this new functionality, a user who is using struts-action-1.3.1 can't just plug in struts-taglib-1.3.1 without upgrading the action jar as well. Throw in several jars each with several versions each, and a user wanting to upgrade just enough to get one specific feature, but not to all the newest jars, and you can understand where the confusion can come from. Hubert Hubert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
