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:
[snip]
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.
Agreed.
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."
+1
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 ...)"
Exactly.
Jim
--
Jim Fulton
Zope Corporation
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
