Forma correcta de usar versiones e hitos

Question

¿Cuál es el propósito de las versiones e hitos en Trac? Cómo usarlos? ¿En qué se diferencia el hito de la versión?

Answer 1

Una buena forma de ilustrar la diferencia es pensar en un ticket de defecto. Cuando archiva el ticket, usted (el remitente del ticket) utiliza el campo versión para indicar la versión del software que muestra el defecto. Una vez que el mantenedor del software triages el ticket, lo asignan a un hito que indica el marco de tiempo en el que se reparará el defecto. El ticket se puede reasignar de un hito a otro dependiendo del cronograma del proyecto, pero el número de versión seguirá siendo el mismo. Los números de versión se refieren a cosas que ya se han lanzado, y los hitos se refieren a cosas que están en desarrollo o planificadas para el futuro y que aún no se han iniciado.

Algunos proyectos tienen una asignación 1: 1 entre versiones e hitos. Por ejemplo, el proyecto Trac en sí tiene un hito para las versiones 0.12.3, 0.13, 0.14, etc. También tienen más hitos abstractos que no se asignan a una versión en particular, como "next-major-0.1X" (que indica cuál es el siguiente lanzamiento principal), "no aplicable" y "no programado". Sin embargo, cuando vaya a crear un boleto, las únicas cosas que se enumeran en el campo "Versión" son versiones lanzadas y versiones en desarrollo activo.

Sus hitos no se tienen para correlacionarse con sus versiones de ninguna manera si no lo desea. Por ejemplo, puede crear hitos para "octubre-2011", "noviembre-2011", etc. y utilizarlos para programar tareas para que funcionen cada mes. Depende completamente de usted y de las necesidades de su proyecto en particular.

Answer 2

Las versiones generalmente son más para lanzamientos a los usuarios.

Milestones son más para los pasos que deben realizarse en el desarrollo. Los usuarios no ven o necesitan estar al tanto de ellos. Algunas tiendas de desarrollo tratan esto como sub-versiones (1.3.2a) que se sumarán a una versión lanzada (1.3.2).

Hay una buena discusión de eso here.

Answer 3

El flujo de trabajo es algo como esto:

• Tienes entradas, que puede ser solicitudes de nuevas características, correcciones de errores, mejoras, etc.
• A continuación, decidir qué entradas tienen prioridad más alta (sobre la base de tal qué necesitan los usuarios o cuán crítica es una corrección de errores, etc.).
• Para organizar el trabajo (y los desarrolladores involucrados), puede decir algo como "un hito será de 2 semanas" (podría ser más, podría ser menos, depende de usted)
• Luego, puede estimar cuántos de esos boletos se pueden resolver realmente en ese período de tiempo (1 hito).
• Luego, puede lanzar una nueva versión cada cierto número de hitos (es decir, una publicación pública después de 1 o 2-4 hitos, a menos que se necesite reparar algo crítico).

En resumen, las versiones están destinadas a ser versiones de trabajo completo (ya sean públicas o no). Y los hitos son la hoja de ruta para esas versiones. Los boletos son la unidad mínima de trabajo que se puede hacer en cada uno de esos hitos.