Control de fuente y trabajo en la nueva versión de la aplicación

Yo uso Mercurial / TortoiseHg como mi control de fuente.

Hasta ahora tengo una sola aplicación y estoy a punto de terminar la versión 1.0. Una vez que V 1.0 se active, ya tenemos las características alineadas lists para ser progtwigdas para la próxima versión.

Es una aplicación de teléfono y ahora mismo V1.0 será gratuito, pero es posible que desee pagar V2.0 y, más adelante, podría realizar algunas actualizaciones de errores / correcciones menores en la versión gratuita.

No estoy seguro de cómo funcionará la corrección de errores mientras V2.0 está en progreso.

Mi pregunta es:

¿Debo bifurcar o ramificar mi repository desde el punto de V1.0 o simplemente sigo agregando funciones a mi repository actual? Lo que sea que necesite hacer, también me gustaría saber por qué tengo que hacer eso.

Gracias.

Haría lo siguiente:

Etiquete la revisión que publica como v1.0

hg update -r <revision that's 1.0> hg tag v1.0 hg ci -m 'Created V1.0 Tag' 

Crea una twig para cualquier corrección de errores que vaya más allá. Esto podría ser cuando liberas V1.0, o cuando tienes la primera corrección de errores para ello.

 hg update v1.0 (or ideally the revision that added the V1.0 tag if it's immediately after V1.0) hg branch release_v1 <Possibly do bug fix> hg ci 

Regrese a la twig pnetworkingeterminada para continuar el desarrollo de v2.

 hg update default <carry on working> 

Cuando tienes una corrección de errores para v1

 hg update release_v1 <do bug fix> 

A continuación, combine las correcciones de errores de v1.x a v2.x

 hg update default hg merge release_v1 hg ci -m 'Merged V1 bug fixes into V2' 

Usted crea nuevas tags a medida que hace nuevas versiones. La twig release_v1 simplemente continúa, acumulando correcciones de errores, fusionándose a la default (su twig de desarrollo) cuando es necesario. Solo asegúrate de estar en la twig pnetworkingeterminada cuando te fusionas, ya que eso determina qué nombre de twig tiene el set de cambios de fusión.


Editado para agregar que esta es una variación en el flujo de trabajo stable / default que alguien más mencionó, pero me gusta tener una twig para cada lanzamiento principal ya que entonces puedo tener más de una versión principal aceptando correcciones de errores.

Un flujo de trabajo común es tener dos twigs, stable y default . Agregue nuevas características a las default y fusione a stable cuando esté listo para lanzar una nueva versión. Los virus vivos se reparan en la twig stable y se vuelven a default por default .

Esta página lo describe bastante bien.

Crearía una twig para 2.0, agregaría sus adiciones y las fusionaría en 1.0 cuando terminen o crearé una versión labelda de 1.0 para savela para fines de file.

Los mantendrá separados porque desea poder recuperar la versión 1.0 en caso de que se necesiten correcciones de errores o una nueva implementación.

Enhorabuena, la cosa es que una vez que su aplicación entre en funcionamiento, probablemente tenga que arreglar errores y hacer algunas actualizaciones menores, pero corregir esos errores o actualizaciones menores podría interferir con su trabajo en 2.0, por lo que sería prudente simplemente bifurcar, corregir errores como vienen y se propagan a 2.0 si surge la necesidad.