[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility

[Jens Vagelpohl]

On 20 Dec 2005, at 21:56, yuppie wrote:
>> yes, i believe the agreement was to try to keep 1.6 as close to  
>> 1.5 as possible, with the exception of GenericSetup.  the types  
>> stuff is the greyest area, however, because the changes in the way  
>> TypeInfo objects are handled btn 1.5 and 2.0 has a considerable  
>> impact on the setup profiles and the import/export nodes.  my  
>> original idea was to have the 1.6 types import adapter use the 2.0  
>> style, containment-based profile format, but to generate 1.5 style  
>> TypeInfo objects.  i haven't had time in recent weeks to keep up  
>> w/ all of the stuff that you've been doing, yuppie, but i do have  
>> a bit of concern that we're causing too much divergence btn 1.5  
>> and 1.6 operationally.  if we stray too far, then tres will stop  
>> forward-porting any 1.5 fixes that he might make... ;-).
>
> I really don't care much about how this is resolved. But from Rob's  
> checkins and the discussion following this mail
>
> http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html
>
> I had the impression that CMF 1.6 should provide backwards  
> compatibility for Products written for Plone 2.1, not for Plone 2.1  
> itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I  
> would be surprised if any other Plone product registers its own  
> type info class. AFAICS the same applies to FlexibleTypeInformation  
> and CPS.
>
>
> I don't think that my backports from the trunk widened that gap  
> between 1.5 and 1.6. It existed from the beginning of the 1.6 branch.

I have a feeling that I am the first one who tried to run Plone 2.1  
on CMF 1.6, which is why no one noticed before. I certainly would  
have spoken up if I had come across it as I have now.

After reading the thread you mention, which isn't all that clear when  
it comes to outlining what the consequences of some of these code  
changes are, I'm confused. I think I can boil it down to one  
question: What is the use of the CMF 1.6 branch if it is not  
compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and  
possibly not even 2.2 since that's only a few months down the road?

I don't quite understand the distinction between "compatible with  
products written for Plone 2.1 but not with Plone 2.1", I can't see  
any sense in that route... it all comes back to one question: What is  
the goal for the 1.6 branch? What specific audience is it targeted  
at? I can see what it's apparently *not* targeted at: People who work  
with Plone 2.1 - including those that might be interested in taking  
up GenericSetup for their Plone product. I had thought that was our  
audience.

jens