cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [cocoon-2.2] Deprecation
Date Thu, 08 Nov 2007 13:53:18 GMT
On 07.11.2007 15:52 Uhr, Grzegorz Kossakowski wrote:

>> Now, at some point we have to break compatibility to get a cleaner
>> architecture and an even better way of doing things. Perhaps removing
>> sub sitemaps is one of these things, perhaps not.
> 
> Before we start to think about migration path and embedding 2.1 as "emergency help" for
existing
> users I really think we should agree what we are going to deprecate and remove in the
future and
> most importantly how we envision future Cocoon's architecture so there will be no "perhaps
yes,
> perhaps no" doubts any more.

It seems we do not even know the requirements. How do you want to decide 
about architecture without them? My guess - since Cocoon is just a 
framework - you merely get the requirements from real applications built 
on it. Why can't we wait until the people get used to the new 
functionality and see how it works out to see what can be removed in the 
future?

 From what I understand servlet protocol lacks some major functionality 
like the fall-through of sub sitemaps. This seems to be the most 
important convention over configuration feature.

> If people don't want to migrate I would tell them to stick to 2.1, it's stable and final
release of
> 2.2 won't make 2.1 unusable.

I want them as testers sharing their experience. Otherwise it takes much 
longer to get peoples to use Cocoon 2.2 in a meaningful way (= more than 
starting with little applications). I don't see the point preventing 
people from migrating. Also we are talking about *deprecation* in 2.2 
here, not removing features. So how should it affect them?


Joerg

Mime
View raw message