cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Thu, 26 Sep 2002 11:28:36 GMT
Carsten Ziegeler wrote:

>Stefano Mazzocchi wrote:
>  
>
>>-1 for 2.1, no question about it.
>>
>>It is true that Cocoon needs a much better component containment
>>technology for us to be able to implement cocoon blocks as designed so
>>far.
>>
>>But you have my word that I'll continue to -1 any change to the 2.x
>>family of Cocoon releases if some fundamental contract like marking
>>interface to represent component behavior stop working.
>>
>>My suggestion to the current avalon developers that share Cocoon's
>>concerns (not all of them do) is: think incrementally, think about
>>migrations paths, think about small evolutionary steps.
>>
>>I know (by experience) that this is extremely hard to do (or take a huge
>>amount of time and energy) but Cocoon *is* a stable technology and we
>>want to continue it to be.
>>
>>We will not change some fundamental interfaces or contracts any time
>>soon.
>>
>>Let me repeat this for those worried guys that are reading this thread:
>>
>> WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET
>>
>>    
>>
>Couldn't have said this better - and really don't mean this ironically.
>
>So, let's put this with the blocks on our new list for 2.2.
>  
>

+1. Same feeling about Stefano's answer : we *need* stability, or nobody 
will want to use Cocoon for a large or long-lived project.

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message