A while ago, we had a discussion about backward compatibility and decided that only major releases should be backward compatible. So, for example, a 1.2 release should be backward compatible with a 1.1 release, but a 2 release could be backward incompatible with a 1 release. We then said we wanted a nice way to spell depending on a major release. (The current way to spell depending on a major release is "foo >=R.dev <R.dev", where foo is the project name and R is the major release number.)
We recently had an opportunity to experience this with zc.relationship. zc.relationship 2 was released and some packages were updated to require zc.relationship 1. Unfortunately, not all of the packages we use were updated and this caused version conflict errors. (This was partly a result of setuptools weak conflict resolution algorithm.) My initial response was, "oh, we need to update all of the other packages that depend on zc.relationship to require version 1." But then I started wondering how we would migrate to version 2 and realized that it was going to be rather hard. All of the dependent packages would have to move in lock step and we'd be back to a monolith. This was enough to make me think that backward incompatible changes are just untenable. I gave a hint to this in some later email threads.
Since then, I've looked at a number of packages that we've split out from Zope that have excessive dependencies. zope.component is a great example. The excessive dependencies (at least the hard ones to deal with) are a result of poor factoring of functionality at a time when dependencies didn't matter. Unfortunately, I think the only way to fix some of these is to split off functionality, which will introduce backward incompatibility.
I eventually came to the conclusion that our original conclusion was sound, but that we should only introduce backward incompatibilities when the need is very dire, as it will cause lots of pain.
Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
