On Monday 23 May 2005 14:18, Ralph Goers wrote: > Is this your perception of just Cocoon or all open source development.
I would say all software development. IMHO, frequent smaller changes is by far a much more effective way to progress a codebase. The longer the cycle, the more important your points below becomes. > 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. This is the typical argument against "frequent releases". I happen to disagree that next release won't be any better, because of new bugs. If it is worse, then the people behind the product is careless. New bugs have a strong tendency to appear in new code (refactorings included), mostly not because smaller fixes of found problems. > But until this is accomplished I am not in favor of creating an > unstable codebase. Of course noone is in favour of creating a unstable codebase _of_what_is_being_used_. Take Ant as an example of fairly good release management (cycles slightly longer than I would like, esp 1.6.2 -> 1.6.3, but still...) The 1.6 branch has had 5 releases in ~ a year and half. In those releases, the 1.7 features are added along side with bug fixes. The 1.7 features have had quite a lot of bugs (relatively speaking). Does that make Ant 1.6 unstable?? IMO, not at all. Do you have a problem using the latest Ant, without extensive internal testing? I don't think you have a problem. What is expected to work, works. The new stuff is somewhat shaky. Typical for software evolution. Cocoon is strange, since so called 2.2 features were 'back ported' to 2.1, to a point where even some experts here is not sure what 2.2 is actually offering over 2.1. Doesn't this make 2.1 unstable as well, then? Suggestion; Try it. If it doesn't work, you can always go back. And if it makes you feel better, put some large disclaimers on the parts that you think is unstable. Listen to the founding fathers of this project, who declared (and lived by it in the 1.x days) "Release Early, Release Often". Everyone here talks about it, but doesn't live by it. Cheers Niclas
