[Zope3-dev] Backward compatibility and major releases (series)
update
Jim Fulton
jim at zope.com
Wed Aug 22 15:57:49 EDT 2007
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:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Zope3-dev
mailing list