[Zope3-dev] package branches

[Gary Poster]

On Jul 2, 2007, at 9:42 PM, Jim Fulton wrote:

Thanks for reply.  quick notes:

> I think that in *technically* depending on a newer version  
> introduces a backward incompatibility. (It's like strengthening a  
> precondition of a method.)  This is especially a problem if people  
> are specifying upper limits for their requirements, which is only  
> necessary if there backward incompatible changes.  ZODB 3.9 won't  
> be backward incompatible in any meaningful way.
>
> ZODB 3.9, like 3.8 *is* backward incompatible because it drops  
> features that we agreed, as a community, to drop. Arguably, ZODB  
> 3.8 should have been ZODB 4 and ZODB 3.9 should be ZODB 5, but I  
> don't think we want to do that.
>
> So, let''s say, as a practical matter, that ZODB 3.9 is backward  
> compatible with 3.8.  We don't know that 3.9 is ready for use yet.   
> It's possible  that there have been bugs introduced in 3.9 (or soon  
> will be) that will be discovered and fixed during the beta cycle.   
> Many people rightly don't want to depend on 3.9 until it has been  
> released in a final form.
>
> Bernd has suggested a policy that I think we should adopt, which is  
> that a package's release status should be no higher than the status  
> of it's dependencies. So, for example, if A depends on a dev  
> version of B, then the version of A that has this dependency should  
> be a dev version.  A should not be able to go to alpha, or beta, or  
> final without a corresponding advance of its dependency on B.

Unless I misunderstand, this is what I did, actually, and Bernd (and  
probably others) didn't like it.  That is, I have a zope.org/ 
distributions release of zope.app.keyreference 3.5 dev and ZODB 3.9  
dev, and I said that keyreference 3.5 depended on ZODB 3.9 dev.

I like the proposal you and Benji came up with.  In that case, would  
what I released (except that I used "-dev" rather than "dev") be  
correct?

...

>> - For this particular problem, I wish my ZODB changes could go  
>> into ZODB 3.8.  As I mentioned in the commit message, the change  
>> includes one bug fix for a potentially serious problem that could  
>> cause data integrity issues;
>
> This could go into 3.8.
>
>
>> one new feature (more informative PersisntentReferences) that  
>> supports an arguable zope.app.keyreference bugfix (conflict  
>> resolution breaks with persistent key references;
>
> Can you remind me or point me at something that describes in more  
> detail?

ZODB/ConflictResolution.txt line 226 ff.

> Does zope.app.keyreference work as well as it does now without this?

I haven't tested it, but yes, I believe it should.

>
>> and one feature (conflict resolution now supports multi databases).
>
> This is a bug fix and could go into 3.8.
>
>>   Then I'd argue that the zope.app.keyreference change could go  
>> into 3.4.
>
> Are we really talking about 3.4?

Yes, zope.app.keyreference.  "Not breaking BTree conflict resolution"  
could be cast pretty easily as a bugfix.

>
>> - Even if people agreed with me for the previous bullet, that  
>> doesn't make this kind of problem go away.
>>
>> - Also for this particular problem, I suppose I could remove the  
>> dependency on ZODB 3.9 and add a test to show that it should still  
>> "work" (as well as it did before at least) with ZODB 3.8  
>> persistent references.  I'd really rather not, of course, but I  
>> can do it in the next week and a half.  I guess it would still be  
>> "3.5" but it wouldn't depend on 3.9 (...except to actually have  
>> any improvements over 3.4!)
>
> I think you should do this or make your version of  
> zope.app.keyreference a dev version.

OK, I'll see what I can do

...

>> My current opinion is that version numbers are the best solution  
>> of a bad lot.
>
> I think we really need a way to limit the algorithm for finding  
> distributions to avoid immature (releases).
>
> I just brainstormed this with Benji and we both think that it would  
> be enough to have an option that says: "I prefer final versions"  
> meaning that we always want the latest final version that satisfies  
> our requirements, if there is one.  Ideally, this would be a  
> setuptools option, however, this would be a new feature and I don't  
> think we'll see new setuptools features any time soon.  I could add  
> this as an option to buildout.

sounds good to me.  Being able to override it for individual packages  
would be important for me.

Gary