On Monday 23 May 2005 02:32, Daniel Fagerstrom wrote: > Hmm, that is to overdo it IMO. Plans and todo lists and Bugzilla entries > can be very usefull for knowing what is left todo, weak points etc. The > problem is when we put together a number of todo lists and say that they > constitute the next minor version, it works for companies but it just > doesn't seem to work for a volontary project like our.
My two cents. 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'. 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. Further down the road, breaking codebase system apart, allowing individual release cycles for core vs each block should also help in shortening the cycle. "Ok to release?" "yeah, yeah, yeah." "I'll do it!" ./release.sh 2.5.1[enter] done. Cheers Niclas
