Лучшая практика управления изменениями сторонних библиотек с открытым исходным кодом?

Question

В недавнем проекте мне пришлось изменить библиотеку с открытым исходным кодом, чтобы устранить функциональный недостаток. Я следил за лучшей практикой SVN по созданию репозитория «источник-поставщик» и внес свои изменения там. Я также отправил исправление в список рассылки этого проекта. К сожалению, в проекте есть только несколько сопровождающих, и они очень медленно фиксируют обновления.

В какой-то момент я ожидаю, что библиотека будет обновлена, и я ожидаю, что мой проект захочет использовать обновленную библиотеку. Но теперь у меня есть потенциальная проблема ...

Я не знаю, применил ли мой патч к этой будущей версии сторонней библиотеки. Я также не знаю, будет ли мой патч по-прежнему совместим с внутренней реализацией обновленных компонентов. И, по всей вероятности, кто-то еще будет поддерживать мой проект к этому моменту.

Должен ли я назвать библиотеку особым образом, поэтому ясно, что мы внесли специальные изменения (например, commons-lang-2.x-for-my-project.jar)? Должен ли я просто документировать патч и ссылаться на местоположение SVN и ссылку на элемент списка рассылки в README? Ни один вариант, о котором я не могу думать, кажется безумным в сценарии обновления.

Какова наилучшая практика для этого?

Answer 1

Отрасли глава СВН «Красная книга» покрывает эту скважину. Пример, приведенный в этой главе, кажется, соответствует вашей ситуации тесно:

http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html

...
Теперь вы сталкиваетесь интересную ситуацию. Ваш проект может размещать собственные изменения сторонних данных в некотором разрозненном виде, например, использовать файлы исправлений или полноценные альтернативные версии файлов и каталогов. Но они быстро становятся головными болями в обслуживании, требуя какого-то механизма, с помощью которого можно применить свои пользовательские изменения к стороннему коду и потребовать регенерации этих изменений с каждой последовательной версией стороннего кода, который вы отслеживаете.

Решение этой проблемы заключается в использовании ветвей поставщиков. Филиал поставщика - это дерево каталогов в вашей собственной системе управления версиями, которая содержит информацию, предоставленную сторонним сущностью или поставщиком. Каждая версия данных поставщика, которую вы решили поглотить в своем проекте, называется отказом поставщика.
...

Answer 2

Помимо ответа Берта, который хорош, насколько управления источником часть вопроса, то я бы также предложить вам написать несколько модульных тестов, которые покрывают ваши изменения.

И не поймите меня неправильно, я не хочу сказать, что вы должны просто написать один или два модульных теста, а затем забыть об этом. Для того чтобы регрессионное тестирование/модульное тестирование действительно работало, его необходимо внедрять систематически, и он должен стать последовательной частью процесса автоматического построения проекта.

И, очевидно, это тоже нелегко, если вы ушли, у вас не будет гарантии, что ваша замена/ваши сотрудники продолжат использовать вашу стратегию тестирования. Так что это тоже то, что вы должны документировать, уточнять, облегчать работу и постоянно обучать своих коллег и руководство.