This kind testing would better be done indeed. Thing is though, it should be done **by testers, not by developers**. In that sense, it's neither your nor library developer's job. <sub>From what you describe it sounds like there are no testers in the project - if this is the case, that's a management problem, and quite a serious one.</sub> > ...saves time as they can read the libraries source code to determine if required functionality is available Quite lame reasoning. When most recent version library fails to compile with most recent version project, there could be multiple various reasons for that - just drilling into lib source code could be waste of time. * What if library is OK and build failure was caused by the bug in project code? Or, what if build failure was caused by temporary incompatible change that is supposed to be corrected a day or two later? What if a build failure indicates a complicated integration issue that will take a week or month to address? For an integration issue, would using a prior version library make a workaround or not? Whatever the reason could be, doing preliminary analysis of the failure would mean wasting developer's time on a work that is supposed to be done by testers. Another thing above reasoning misses is inevitable (and quite painful in my experience) productivity losses that follow when one has to [break the flow](http://en.wikipedia.org/wiki/Flow_%28psychology%29) by switching between development and QA activities. --- When there are testers in the team, such things are really simple and can be handled much easier. What your "senior" developer cast at you is basically a draft testing requirement. > Upon every change made to the project or library, make sure that build is successful. Steps to proceed from there are typical QA activities: clarify requirement details, design a formalized test scenario, negotiate on how to handle test failures. * From [SQA](http://en.wikipedia.org/wiki/Software_quality_assurance) perspective, this is quite a routine task of designing, setting up and maintaining a pretty simple [regression testing](http://en.wikipedia.org/wiki/Regression_testing) procedure that could be highly automated - probably up to the point that only manual activity would be creating and maintaining tickets in [issue tracker](http://en.wikipedia.org/wiki/Issue_tracking_system) and verification of fixes.