¿La mejor práctica para gestionar cambios en bibliotecas de código abierto de terceros?

Question

En un proyecto reciente, tuve que modificar una biblioteca de código abierto para abordar una deficiencia funcional. Seguí la mejor práctica SVN de crear un repositorio de "fuente de proveedor" e hice mis cambios allí. También envié el parche a la lista de correo de ese proyecto. Desafortunadamente, el proyecto solo tiene un par de mantenedores y son muy lentos para enviar actualizaciones.

En algún momento, espero que la biblioteca se actualice, y espero que mi proyecto quiera utilizar la biblioteca actualizada. Pero ahora tengo un problema potencial ...

No sé si mi parche se habrá aplicado a esta versión futura de la biblioteca de terceros. Tampoco sé si mi parche aún será compatible con la implementación interna de los componentes actualizados. Y con toda probabilidad, alguien más mantendrá mi proyecto en ese punto.

¿Debo nombrar la biblioteca de una manera especial, por lo que está claro que hicimos modificaciones especiales (por ejemplo, commons-lang-2.x-for-my-project.jar)? ¿Debería documentar el parche y hacer referencia a la ubicación SVN y un enlace al elemento de la lista de correo en un archivo README? Ninguna opción que se me ocurra parece ser infalible en un escenario de actualización.

¿Cuál es la mejor práctica para esto?

Answer 1

El Vendor Branches capítulo del SVN "libro rojo" cubre este pozo. El ejemplo de este capítulo parece que coincida con su situación de cerca:

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

...
Ahora se enfrentan a una situación interesante. Su proyecto podría albergar sus modificaciones personalizadas a los datos de terceros de una manera inconexa, como el uso de archivos de parche o versiones alternativas completas de archivos y directorios. Pero estos rápidamente se vuelven dolores de cabeza de mantenimiento, requiriendo algún mecanismo por el cual aplicar sus cambios personalizados al código de terceros y necesitando la regeneración de esos cambios con cada versión sucesiva del código de terceros que rastrea.

La solución a este problema es utilizar ramas de proveedores. Una rama de proveedor es un árbol de directorios en su propio sistema de control de versiones que contiene información proporcionada por una entidad de terceros o proveedor. Cada versión de los datos del proveedor que decide absorber en su proyecto se denomina caída de proveedor.
...

Answer 2

Aparte de la respuesta de Bert, lo cual es bueno en lo que se refiere a la parte de control de origen de la cuestión, También me gustaría sugerir que escribe algunas unidad de pruebas que cubren los cambios.

Y no me malinterprete, no quiero decir que solo deba escribir una o dos pruebas de unidad y luego olvidarse de ello. Para que las pruebas de regresión/pruebas unitarias realmente funcionen, es necesario implementarlas sistemáticamente y deben convertirse en una parte consistente del proceso de construcción automatizado del proyecto.

Y, obviamente, esto tampoco es fácil, una vez que se haya ido, no tendrá garantía de que su reemplazo/sus compañeros de trabajo continúen utilizando su estrategia de prueba. De modo que eso también es algo que debe documentar, refinar, hacer más fácil de hacer y educar constantemente a sus compañeros de trabajo y directivos.