On Oct 6, 2007, at 5:06 AM, Martijn Faassen wrote:

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 release).

I think I agree with the spirit of the above, but not the specifics. You restate the specifics below in a way I whole-heartedly agree with. There isn't a 3.4 "line" of eggs. There could be a set of projects versions associated with a "3.4 release of Zope3", but the individual version number could be almost anything.

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 ...)"



Jim Fulton
Zope Corporation

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to