cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Time based release cylces
Date Mon, 19 Jun 2006 07:00:13 GMT
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>>Before we decide what we call the releases exactly I want to draw our attention 
>>to a decision we made long time ago. We agreed that we want to change to 
>>time-based release cycles instead of the feature-driven releases we had up to 
>>now which wasn't helpful in becoming more agile.
>>Taking this into consideration I think we can stick with giving our releases the 
>>"milestone" postfix. The name "milestone" only says that another period of 
>>development is over ("time-boxing").
>>We only need to decide how long the periods between releases should be. I guess 
>>this will highly depend on the module. The most important modules (e.g. 
>>cocoon-core, cocoon-forms, cocoon-template, cocoon-javaflow, the archetypes, the 
>>deployment plugin) should be released every 4 weeks, other modules every 3 
>>months and there will be modules that will only be released if required. 
>>Additionally we should coordinate the release cycles so that at least twice a 
>>year, we release everything at the same time (IIUC the Eclipse project wants to 
>>make this happen for their universe with the "Callisto" initiative).
> Now, while this really sounds great I fear it's very very difficult. It
> was a hugh effort for the Callisto team (and the participating eclipse
> projects) to get where they are today. And it's really time/resource
> consuming - and as we are short of time/resources anyway, the only way
> this would be possible is to automate the release and simply "do it"
> after each time frame. But I don't think that this is a good idea as
> there is no way to determine the quality of the relese.
> So, in general I agree that we should try it, but not with the cost of
> quality and tested releases.

We are watching quality all the time and we don't even manage to get our stable! 
2.1 branch released. We have to become more agile in our release policy instead 
of the opposite. M2 makes this possible and we should take this chance. And we 
can always decide how we want to tag a release and here I agree with the quality 

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:

View raw message