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
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