Bifurcado un proyecto, ¿dónde comienzan mis números de versión?

12

He bifurcado un proyecto y he cambiado mucho. Esta bifurcación no es solo un pequeño cambio de características aquí y una corrección de errores enterrada allí, es un cambio bastante sustancial. Solo se comparte la mayor parte del código central.

Bifurqué este proyecto en v2.5.0. Por un tiempo comencé a versionar mi fork en v3.0. Sin embargo, no estoy seguro de si esta es la forma correcta, principalmente porque cuando ese proyecto llega a v3.0, las cosas se vuelven confusas. Pero no quiero comenzar de nuevo en v1.0 o v0.1 porque eso implica la infancia, la inestabilidad y la falta de refinamiento de un proyecto. Esto no es cierto, ya que la mayoría del código central es muy refinado y estable.

Estoy realmente perdido en qué hacer, así que pregunto aquí: ¿Cuál es la forma estándar de lidiar con este tipo de situación? ¿La mayoría de las bifurcaciones comienzan de nuevo, aumentan los números de versión o hacen otra cosa que no conozco?

versioning

— TheLQ
fuente

55

No veo cómo 1.0 implica infancia o inestabilidad. Cualquier cosa por debajo de 1.0 sí, pero 1.0 implica que está fuera del período de 'infancia' y está listo para rockear. Si te hace

— sentir

1

Por curiosidad, ¿qué bifurcaste?

— compman

13

La mayoría de las horquillas que he visto comienzan de nuevo desde la versión 1.0. Pero supongo que también ha cambiado el nombre de su bifurcación, por lo que no estoy seguro de por qué habría confusión si simplemente comenzara desde la v3.0.

Lo que haría es cambiar el nombre del proyecto, lanzar la versión 1.0 y dejar en claro que el proyecto es una bifurcación de otro proyecto. No creo que haya ninguna confusión con ese enfoque.

Si está realmente preocupado por la etiqueta "1.0", simplemente lance la versión 2.0 poco tiempo después de 1.0 ...

— Dean Harding
fuente

... o lanzar v2.0 directamente, omitiendo la v1.0 por completo. No sería la primera vez que se hace esto.

— Konamiman

En mi empresa, un proyecto comenzó en v2.4 incluso.

— user253751

6

Tenga su propia hoja de ruta y cúmplala, comenzando con el número de la versión original, pero no intente competir con la versión actual del producto original.

— dukeofgaming
fuente

1

Si no está tratando de poner en paralelo el proyecto original de alguna manera, entonces no habrá una correlación significativa entre los números de versión en el futuro. Eso significa que no tiene sentido tratar de establecer tal correlación ahora, comenzando en 3.0, porque solo establecerá una expectativa insatisfecha.

— Tom Anderson

Estoy corregido. Debes comenzar tu propia v1.0, que te ayudará a diferenciarte. Las versiones deberían significar algo, no solo un truco de marketing (v.gr. "v5.4" simplemente para no parecer nuevo).

— dukeofgaming

1

@TomAnderson: si se bifurca en, digamos, la versión 2.5, y hace que la primera versión de su tenedor sea 2.6 o 3.0, puede señalar a la otra aplicación como el historial completo de su proyecto. Lo cual es una correlación modestamente significativa.

— DougM

3

Es posible que desee considerar si (y cuánto) su proyecto estará relacionado con el original. Si planea portar nuevas características del proyecto original a su, puede considerar mantener sus números de versión que coincidan con las versiones del original.

Como ejemplo, vea MariaDB, que es una bifurcación de MySQL. Quieren mantenerlo como un reemplazo directo para MySQL, por lo que, por ejemplo, MariaDB 5.2 tiene todas las características de MySQL 5.2.

Ver: http://kb.askmonty.org/v/mariadb-versus-mysql

Nota: desde que se publicó esta respuesta, MariaDB se ha distanciado sustancialmente de MySQL y ahora sigue su propio esquema de versiones.

— Mchl
fuente

1

0.1 puede indicar la infancia, pero la versión 1.0+ significa estable. Un aumento en los números de versiones principales, por ejemplo, 2.0, 3.0, generalmente indica un gran cambio de características.

P.ej

La versión 1.0 de mi aplicación era una herramienta para ejecutar scripts de prueba con configuración,
La versión 2.0 eliminó la diferenciación entre los scripts de prueba y los scripts de configuración del entorno,
La versión 3.0 agregó una GUI para escribir scripts como diagramas de flujo. Son productos reconociblemente diferentes, pero incluso la versión 1 era un producto funcional, completamente estable, etc. Las versiones 2 y 3 surgieron porque se decidió que estos grandes cambios serían buenos. Si no hubiéramos querido estos grandes cambios, y hubiéramos seguido haciendo correcciones de errores, etc. Los números de versión menores habrían aumentado, 1.10,1.20, etc., y eso habría estado bien.

Lo que digo es que los números de versión principales no indican madurez, sino que indican conjuntos de características principales. Ahora que fue un poco tangente de cómo numerar su producto.

Lo que he visto antes, lo que me gustó silenciosamente fue comenzar a versionar nuevamente desde 1.0 (o desde 3.0 si realmente lo prefiere) y luego entre paréntesis decir de qué versión del original tenía las características extraídas.

Inicialmente: " MyFork v1.1 (basado en OrigProg v3.0)
Algunas redes mejoradas hechas a MyFork: MyFork v1.3 (basado en OrigProg v3.0)
OrigProg lanzó una versión principal y MyFork sacó y fusionó: MyFork v2.1 (basado en OrigProg v4.0)
Realizó algunos cambios importantes en MyFork (probablemente no podrá fusionarse fácilmente con OrigProg nunca más): MyFork v3.0 (basado en OrigProg v4.0)

— Lyndon White
fuente

0

Si es posible, combine su bifurcación con el proyecto original. No puedo enfatizar esto lo suficiente.

Recupera tus números de versión, luego usa el que bifurcas más un sufijo de fecha.

2

Pasar de "Python 1.1" a "Userthon 1.1. {FECHA}" rompe el formato esperado de los números de versión.

— DougM