I don't know much about CPAN, but using CVS to maintain revisions of the jars that are placed in our repo seems like a viable solution. I believe naming the jars with released versions should still be used. If I'm following right we would really be using cvs as a versioned file system in a sense. We just want to track different versions of the jars when they are named the same ( as the dev version ) and use tags to reference a specific version.
We use Continuous Integration at work and currently keep our repo of third-party jars in cvs. We use a cvs alias to that directory to check out the repo in our project directory structure. While we don't update jars very often, a few times we've ( ahem, I mean me ) jumped the gun, and commited a dev jar that broke something. It is much easier to get the previous version back into the HEAD for the rest of the developers since we were using cvs to store the jars. >I believe that CPAN is release oriented so they don't need to do that. > >Jakarta development tends to be CVS HEAD oriented because most people >doing >development try to keep CVS HEAD relatively stable. Gump also attempts >to >enforce that practice. Also, Jakarta development tends to be more >bleeding >edge and with so many components depending on specific features in so >many >other components, it tends to make sense to use CVS HEAD. >I also like bucking the age old development trend of using only released >software. :-) I believe that coding around released software bugs or >adding >features in a local package instead of a general package is worse than >simply fixing the bug or adding the feature and updating the jar. Using Continuous Integration for our source and the repo for only third-party jars we don't build continuously works great and we build all our applications based on our code from the HEAD of cvs. To accomplish this we had to change our usage of cvs. We no longer check in any code that isn't passing all unit tests for all code. CI is building whenever a change in the repo takes place and a failure is known quickly after the code has been committed. So in a sense, each sucessful build ( not just compiled, but tested also ) could be considered a point release ( in fact we tag all the sources in cvs on each sucessful build ). We rarely ever use branches and don't use cvs as a place to hold our code for the night. If all projects bought into the massive continuous integration idea and kept their cvs HEAD up to par in this fashion, I agree with you, each sucessfull build would, in a way, be a release. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
