On Thu, Jun 10, 2010 at 5:28 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
We are not really changing the API in a BBB incompatible way. We simply shuffled code around. We did that all the time and never increased the major version number.
The code is no longer compatible with older versions of zope.testing and introduces a hard dependency on a new major release of another package. That clearly constitues the need for a major version upgrade in my book. If the code would optionally use zope.testrunner and fall back on the existing zope.testing it would be fine to do this change in a minor release like 1.3. As you can tell from the reported breakage the new release is not backwards compatible.
I think rereleasing zc.recipe.testrunner without the zope.testrunner dependency as a 1.3.1 would be in order. And then releasing the current 1.3.0 code as a new 2.0b1.
I think that would be a bit harsh and not fix the Zope 2 problem, if no versions are pinned, since even 2.0b1 will be picked up as latest.
Some people use the prefer-final option of buildout to guard against unstable software. But more importantly humans checking for new versions or the z3c.checkversions has a chance of identifying this new release as yet unstable. Hanno