Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I don't agree with this:</p> <blockquote> <p>Duplicate untested code is better than common untested code (you break only one project).</p> </blockquote> <p>If you are all equally likely to create bugs by implementing the same thing, then you'll all have to fix potentially <em>different</em> bugs in each instance of the "duplicate" library.</p> <p>It also seems that it'd be much faster/cheaper to write the library once and, instead of having multiple other teams write the same thing, have some resources allocated to testing.</p> <hr> <p>Now to solve your actual problem: I'd mimic what we do with real third-party libraries. We use a particular version until we're ready, or compelled to upgrade. I don't upgrade everything just because I can--there has to be a reason.</p> <p>Once I see that reason (bug fix, new feature, etc.), then I upgrade with the risk that the new library may have new bugs or breaking changes.</p> <p>So, you're library project would continue development as necessary, without impacting individual teams until they were ready to "upgrade". </p> <p>You could publish releases or peg/branches/tag svn to help with all this.</p> <p>If all teams have access to the bug tracker, they could easily see what known issues exist in the upgrade-candidate before they upgrade, too. Or, you could maintain that list yourself.</p> <p>@Brian Clapper provides some excellent guidelines for how to run your library as a project in <a href="https://stackoverflow.com/questions/431007/common-libraries-in-a-large-team#431043">his answer</a>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload