Re: Re: zope.error is a 3.5 egg, but is needed by 3.4.x releases

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