> BUT, this could result in having tens of libs ~= the same. Eg: > turbine-3.0-20020527, > turbine-3.0-20020101, turbine-3.0-20010203, etc... This would fill up > the lib.repo at > light's speed, and would make it really confusing, never knowing which > one to use. > This problem grows exponentially with the number of dependencies. > > IMO, the single lib repo approach forces the developper to choose > between one of both > approaches : stable release OR cvs snapshot. > > If you have enough developpers to work on all your projects in the same > time, and if you > want to use an evolving code, then you choose the "-dev", so that all > coders adapt in the > same time to the same lib, keeping easy the integration (two projects > don't rely on > different APIs).
Hm, good points. For the most part agree with you; -dev should be preferred over timestamps in most situations. What motivated my post was that I spent a long time trying to figure out an error that Torque 3.0-b2 was giving me. The more I think about it, the less convicted I am that -dev conflicts the problem I was seeing, but regardless Torque 3.0-b2 has 5 of it's 13 lib files as -dev versions. So my case was probably rare enough not to worry about; I had a released application that relied on -dev version where those -dev versions where in the lib.repo (my doing) and could be over-written with newer ones. Also, as I browse the Jakarta.apache.org/turbins/jars repository, many of the supposedly -dev versions are old. There are a lot from January, February, and March. If the point of -dev is to be running with the latest, greatest code, shouldn't these be updated on a fairly frequent basis? Thanks, Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
