Re: Backward compatibility and major releases (series) update

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

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

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

Jim

--
Jim Fulton			mailto:[email protected]		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org