On Aug 22, 2007, at 4:15 PM, Tres Seaver wrote:

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 with "evergreen" deprecation

Yup, which is what Gary is doing with zc.relationship.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to