I suspect the best way to think of it is that some of the company libraries are treated like third party libraries and other company libraries are treated differently because they are being worked on.
You don't update compiled or source for, say, Spring that often. When you do update its a big enough deal to change version numbers for your build that you can "download" the source if you need it for debugging. Lots of times the changes between two of these versions are minor enough that using the old source with the new binary works good enough and you don't really care. Treat some of your in-house libraries the same way. Update rarely because it takes time to do it. The rest of the in-house libraries are those "you" are working on and will need to be updated from source control often enough. Usually the pain of debugging a problem when using old source is enough to encourage people to update that source. Or the pain of breaking the build (or the tests) by checking in code that doesn't work because "you" didn't update your source will do it. Someone finds there is a key issue and tells everyone else to update. It just sort of works if you keep the lines of communication open. -- -- Lee Meador Sent from gmail. My real email address is [EMAIL PROTECTED]
