Jim Fulton wrote:
On Oct 5, 2007, at 1:59 PM, Martijn Faassen wrote:
but moved to a new place. zope.app.error, is, I understand, gone now.
I have no idea about this specific move. If there was a zope.app.error
before, then distributions of it should still exist and new
distributions should be backward compatible.
After we fixed a bunch of errors in them, they're backward compatible,
yes. With deprecation warnings. The code moved to zope.error so
zope.app.error is now empty.
I really don't think going from zope.app.applicationcontrol 3.4 beta
whatever, going to final 3.4.1 suddenly means a whole new package should
appear with new deprecation warnings.
I thought that *never* in the 3.4 line of eggs should they *suddenly*
start relying on 3.5 eggs. That's nothing to do with the notion of a 3.4
release, but with the notion that during the stabilization phase, or
with minor bugfix releases, you don't suddenly start relying on a new
feature release of something else (or in this case, an entirely new
Anyway, I think the rule should be:
"When you do a final or bugfix release of a package, you can't start
requiring a new feature release of another package."
Translated to version numbers:
"If X.Y.x has been relying on A.B.x, X.Y.x + 1 cannot start relying on
A.B + n, only on new A.B.x + n releases, where x is one of (b0, b1, 1,
2, 3, ...) and n is one of (1, 2, 3 ...)"
Zope3-dev mailing list