Perl, PostgreSQL hacker; US politics junkie; Webapp developer; Portvangelist; profane iconoclast.
On CPAN see: DWHEELER [cpan.org].
"This will go down in [my] permanent record," eh? I guess I'd better make it good.
There's been quite the debate going on over on the Bricolage developers list. For those who don't know about Bricolage, its a full-featured, open-source, 100% Perl content management system that I maintain on SourceForge. You can learn more abou it here.
Anyway, the debate is over the art and science of CVS management. We've been adding features to both minor and major releases up to now, but there has been substantial argument that the minor releases should be bug-fix only. The advantage of this approach is that new code won't threaten stable releases. The disadvantage is that it could slow development. Quick and easy new features will have to wait for more involved features to be complete before they can see the light of day of a release.
There are some strong opinions, but I'm currently sitting on the fence. More opinions are welcome!
CVS Best Practices (Score:1)
CVS Best Practices [tldp.org] is something you probably already have read. If not, I highly recommend it. As I am writting this, I notice it is not version 1.4, and last I read it was 1.3, so it is a working document.
Also, I found the A.C.M.E. [cmcrossroads.com] website helpful. A.C.M.E. stands for Assembling Configuration
Re:CVS Best Practices (Score:1)
Thanks for the comments, exeunt. I'm not really doing much CVS management these days. I ultimately made a decision, we went with it, and it's working pretty well. I imagine that if I get back into the fray, I'll be checking out your links.