cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: [RT] Releases
Date Mon, 23 May 2005 06:18:50 GMT
Niclas Hedhman wrote:

>Cocoon community is IMHO too focused of NOT releasing something BAD, instead 
>of focusing on releasing the new and good stuff.
>If releases came out on a bi-weekly basis, who would be worried that a bug or 
>two sneaked in. Patch and it will be fixed in days. And with so many 
>community members having sites deployed off the HEAD, I doubt that much 
>regression would occur in reality, and committer sensibility is another 
>'safety net'.
>  
>
> My two cents.

Is this your perception of just Cocoon or all open source development. 
What you are suggesting is unacceptable for use in a production 
environment.  When I release my product I don't want to have update the 
framework every two weeks.  And if there is a bug, the next release 
probably won't be any better. Sure the bug might have been fixed, but 
now will just have new ones because of all the new stuff.  When you 
deploy your production application on Tomcat or JBoss just how often are 
you updating your container?  We do it only when we have a new release 
of our product coming out. We expect the frameworks we use to be 
stable.  And Cocoon is just another container just like Tomcat or JBoss.

I, for one don't deploy from head. I pick a stable release and use that 
and then apply any patches I need to it after extensively testing.

>By trying to minimize(!) the number of new features in each 2.x.0 release, the 
>users have less learning to cope with, when 'inhaling' a new feature release. 
>Going from 2.0 to 2.1 or 2.1 to 2.2 is overwhelming, especially if you have 
>not followed the dev-list.
>  
>
This is a problem because the Cocoon "core" (i.e. - practically 
everthing) is too big.  "Real blocks" are the answer, not changes to 
release management.

>Further down the road, breaking codebase system apart, allowing individual 
>release cycles for core vs each block should also help in shortening the 
>cycle.
>  
>
Here I absolutely agree.  But until this is accomplished I am not in 
favor of creating an unstable codebase.

>"Ok to release?"
>"yeah, yeah, yeah."
>"I'll do it!"
>
>./release.sh 2.5.1[enter]
>
>done.
>
>
>Cheers
>Niclas
>  
>

Ralph


Mime
View raw message