[Zope3-dev] package branches

[Bernd Dorn]

On 26.06.2007, at 21:44, Gary Poster wrote:

>
> On Jun 26, 2007, at 3:29 PM, Bernd Dorn wrote:
>
>>
>> On 23.06.2007, at 12:38, Christian Theune wrote:
>>
>>> Am Samstag, den 23.06.2007, 07:04 -0400 schrieb Gary Poster:
>>>> Hey Christian.  I intend to check in some code that fixes
>>>> zope.app.keyreference conflict error issues I wrote about last  
>>>> week.
>>>> This will take advantage of some code that I checked in to the  
>>>> ZODB,
>>>> that I don't intend to be part of ZODB 3.8--so I don't intend my
>>>> zope.app.keyreference changes to be part of Zope 3.4.
>>>>
>>>> The zope.app.keyreference package has not yet branched.  In your
>>>> capacity as release manager, would you mind if I did that, so I  
>>>> could
>>>> make a 3.5 dev checkin/egg?  Also, I'm a bit confused on our
>>>> preference now: would this be 3.5.0-dev or 3.5.0a1-dev, or what?
>>>
>>> Yes. And if you're at it, I'd welcome if you'd switch the tree's  
>>> trunk
>>> to use that branch. :)
>>>
>>> The trunk's setup.py of the satellite should either be 3.5.0a1 or  
>>> 3.5.0.
>>
>> i think as long the package has a dev dependency like ZODB 3.9 it  
>> should at least have alpha or beta status
>
> Hi Bernd.
>
> Why?

because it pulls in software that has development status like zodb   
3.9 and the release of 3.9 will take at least a half a year from now  
on imho.


>
>> gary, is it possible to be compatible to 3.8 too?
>
> Not productively.  We could have "if the PersistentReference  
> doesn't have the 3.9 stuff then just refuse to do a ConflictError"  
> but then that's no different that the keyreference 3.4 behavior.   
> Heh, actually, that's effectively the behavior we probably have now  
> for keyreference 3.5dev running against ZODB 3.8, since errors in  
> the conflict resolution will simply cause the resolution to fail,  
> and the 3.5dev changes would generate AttributeErrors against ZODB  
> 3.8 during conflict resolution.
>
> So...it would be a bit of a lie to claim to be compatible with  
> 3.8.  The changes are useless without the 3.9 changes.  But the  
> code *should* technically work with the same restrictions we have  
> now.  That said, I don't really want to support the changes against  
> 3.8.
>
> ...I could move the releases to our ZC download location, rather  
> than the zope.org one, if folks want...

i don't think that this is a good idea, for example our company uses  
both of the download locations

>
> What's the problem?  I'm happy to help, especially if it doesn't  
> take too much time, and you can wait a day or two.

ok, i think if another new feature is implemented in keyreference and  
we want this feature for zodb3.8 we have to do a version inbetween,  
so if you call this a 3.5 release, what should that other version  
be?  3.6

we use egg based releases and if you hardcode the zodb 3.9 dependency  
in setup.py we have to switch to zodb3.9 just because of that package  
if we want to use a new feature of it

maybe i am anticipating here and it's best to make it zodb 3.8  
compatible when we need a newer version of keyreference for some  
reason. the problem with this is, that we (zope committers) can do  
this, but another company may not be able to change the package.


>
> Gary