-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote: > 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.
+1. Cleanliness is not a good enough reason to break a public API, for instance. If necessary, the incompatible stuff might be better off moving to a new package / API name altogether, with the old name left as a pure compatibility shim (perhaps wich "evergreen" deprecation warnings). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzJld+gerLs4ltQ4RAjDFAKCcf9tlJhiSM+7VPkH1QmnJx/YGHQCdEOyN hyuU4a1s+apbrtT1mDh4hgE= =suL+ -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
