Etiqueta: ¿Versión tope mi fork del proyecto opensource?

Question

Esta pregunta trata sobre la etiqueta y los proyectos de código abierto.

He bifurcado una aplicación de github y he agregado dos nuevas características.

1. El primera característica ha sido pedido con frecuencia en otro lugar. Lo he agregado La implementación del código & está limpia (creo).

2. La segunda característica es más de un truco. Será de utilidad para otros, pero la implementación es un poco sucia en uso y más aún en el código. Necesito la función, pero no tengo las habilidades para implementarla completamente o a un nivel que podría considerarse vale la pena contrabution para el proyecto principal.

¿Cómo debería funcionar el control de versiones? ¿Acabo de actualizar mis números de versión sin cuidado y presionar a mi rama principal?

Es molesto saber qué versión se está ejecutando, modificada u original, ya que ambas tienen el mismo número de versión. Pero será confuso cuando, meses después, mi página github tenga un número de versión igual al original, pero ambos son completamente diferentes. (He hecho una solicitud de extracción, etc., pero que no es el contexto de mi pregunta.)

El proyecto que he bifurcada utiliza joyero rubí por lo tanto tiene un formato de versiones de:

joyero seguimiento de la versión de su proyecto. Asume que usará una versión en el formato x.y.z.

x es la versión 'principal', y es la versión 'menor', y z es la versión de parche.

¿Es este estándar para otros proyectos/idiomas también? ¿Son mis cambios parches?

Gracias

Answer 1

Esto no se puede responder fácilmente. El manejo del número de versión varía entre los proyectos y sus objetivos. ¿Ves tu tenedor como un problema temporal? - Entonces, en muchos casos (podría ser diferente con reescrituras más grandes, por ejemplo), no aumentaré el número de versión, ya que depende del líder del proyecto.

Muchos esquemas de control de versiones permiten extender el número de versión a algo así como 1.2.3-ross, que ayuda a los usuarios a presentar informes de errores adecuados.

Si planifica una horquilla de funcionamiento más largo, debe encontrar un esquema de control de versiones que funcione para usted.

Answer 2

diferentes piezas de software a partir de la misma base de código, pero con diferente contenido de las funciones deben tener diferentes números de versión de alguna manera - por lo que necesita cambiar algo en el número de versión (o nombre del producto).

¿Tiene previsto enviar el primer cambio al proyecto? (Probablemente deberías).

¿Es la segunda característica, el truco, una que mejorarás con el tiempo? Puede mantenerlo en su propia rama de desarrollo para que sea más fácil mantenerlo por separado mientras sigue importando las actualizaciones del proyecto principal.

¿O planea permanecer separado del proyecto principal a perpetuidad? En ese caso, debería considerar renombrar el software así como cambiar la versión, o de alguna manera dejar en claro que la versión es suya y no suya.

Answer 3

Si tiene intención de fork, es decir, nunca volver a fusionarse con la versión anterior, considere cambiar el nombre de su proyecto.

lo contrario, es común el uso de un número de versión que indica la rama y de cambios siendo RAN ala -git-ross-12345