La única razón por la cual el hito 3.3.3 se marcó como completado es porque dejar el hito abierto interfirió con nuestros informes de tickets para 3.4.1. (Olvidé que los cierres de hitos se reflejan en la línea de tiempo).
En términos generales, asignamos tickets al siguiente hito menor si informan una regresión inmediata. Entonces, una regresión en 3.2 que aparece durante el desarrollo de 3.3 habría sido asignada a 3.2.2, como sucedió aquí. En este caso, llegamos a cerrar estos tickets con un commit contra la sucursal 3.2. A veces hacemos esto principalmente por razones de limpieza y, por lo tanto, si existe la necesidad de un lanzamiento, estamos más preparados. Pero como nada desencadenó una versión 3.2.2 (un error suficientemente crítico o algo relacionado con la seguridad), acabamos de cerrar el hito. Esto es útil para fines de seguimiento. Podríamos haberlo eliminado con la misma facilidad y reasignar todos los tickets a 3.3. Simplemente no lo hicimos en este caso.
Editar, agregando más antecedentes: Vale la pena señalar que siempre nos esforzamos por que las ramas de la versión sean lo más estables posible. Entonces, si está ejecutando la rama 3.2 y siempre la mantuvo actualizada, podría estar ejecutando algo "más estable" que la versión estable 3.2.1. Este tipo de arreglos adicionales a menudo entran en una rama después del lanzamiento del punto final para esa rama, y por lo tanto no se liberan.
Hemos lanzado paquetes formales en raras ocasiones: 3.0.6 se lanzó al mismo tiempo que 3.1.2. En general, hemos tratado de mantener la segunda rama más nueva (por ejemplo, 3.0) hasta que la rama de desarrollo actual (por ejemplo, 3.2) haya alcanzado el estado "beta". No anunciamos la disponibilidad de 3.0.6, pero cualquiera que ejecute la rama 3.0 al menos podría haberse actualizado a esas correcciones a través de canales oficiales.