[Zope3-dev] Re: Backward compatibility and major releases (series) update

[Tres Seaver]

-----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          tseaver at palladion.com
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-----