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 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 Corporationhttp://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
