[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