Best practice for managing changes to 3rd party open source libraries?

Posted by Jeff Knecht on Stack Overflow See other posts from Stack Overflow or by Jeff Knecht
Published on 2011-02-05T22:44:51Z Indexed on 2011/02/05 23:26 UTC
Read the original article Hit count: 209

Filed under:
|
|

On a recent project, I had to modify an open source library to address a functional deficiency. I followed the SVN best practice of creating a "vendor source" repository and made my changes there. I also submitted the patch to the mailing list of that project. Unfortunately, the project only has a couple of maintainers and they are very slow to commit updates.

At some point, I expect the library to be updated, and I expect that my project will want to use the upgraded library. But now I have a potential problem...

I don't know whether my patch will have been applied to this future release of the 3rd party library. I also don't know whether my patch will even still be compatible with the internal implementation of the upgraded components. And in all likelihood, someone else will be maintaining my project by that point.

Should I name the library in a special way so it is clear that we made special modifications (eg. commons-lang-2.x-for-my-project.jar)? Should I just document the patch and reference the SVN location and a link to the mailing list item in a README? No option that I can think of seems to be fool-proof in an upgrade scenario.

What is the best practice for this?

© Stack Overflow or respective owner

Related posts about svn

Related posts about open-source