No importa realmente si se trata de una biblioteca o de una aplicación más grande. Un esquema de versionado semántico funciona perfectamente bien para aplicaciones grandes. Incluso se puede usar para una colección de aplicaciones empaquetadas en una plataforma, pero aquí se vuelve bastante difícil de abordar.
La pregunta principal es si se va a seguir la ruta de la depreciación soportada en una versión y solo la eliminación en la próxima versión principal. Tener funcionalidad obsoleta pero soportada puede requerir bastante esfuerzo. Cuando se van a realizar cambios en el modelo de datos persistente, la depreciación a menudo se vuelve imposible. Si eso sucede, ni siquiera se puede hacer una versión menor con funcionalidad obsoleta, y se salta instantáneamente a la siguiente versión principal. Esta es la parte donde las aplicaciones grandes suelen tener problemas. Se pasa de 3.0.0 a 3.0.1 a 4.0.0 porque no se puede proporcionar compatibilidad con versiones anteriores. Si a menudo hay cambios disruptivos, adherirse a semver aporta poco valor.
Dicho esto, prefiero mucho más esa construcción porque comunica más claramente a los desarrolladores que habrá cambios disruptivos. El esquema AAAA.N no me dice nada como desarrollador, ni como administrador.
Entonces, la pregunta es, ¿qué quieres comunicar con la versión? Si quieres hacer 6 lanzamientos de funciones (que pueden ser o no disruptivos), y cada 6º lanzamiento tendrá un soporte más prolongado con parches; y no quieres versionar los lanzamientos de parches. Entonces X.Y es un esquema adecuado donde Y=0 es el más prolongado. X sería solo un número. El problema es que cuando X es el año, Y se asocia rápidamente con un mes. ¿Entonces los lanzamientos más nuevos y de soporte más prolongado se lanzarán en enero? Siempre tengo que buscar qué versión de Ubuntu es LTS, lo que me molesta.
Entonces, ¿qué pasa si Discourse simplemente continúa con la versión principal actual? La próxima versión de soporte más prolongado se llama 4.0; y luego obtenemos 4.1 a 4.5 como lanzamientos de funciones; seguido de 5.0 que es el más nuevo de soporte más prolongado.
Entonces tampoco tendrás ese momento incómodo en el que un lanzamiento se retrasa debido a un problema importante.
Opcionalmente, puedes agregar un número de “parche” si planeas lanzar parches explícitamente (en lugar de tener lanzamientos de parches continuos). “Pero entonces tienes x.y.z que es semver”. Bueno, no, parece semver, pero no lo es. Cada nueva versión “menor” puede ser disruptiva. Así que sugiero simplemente ceñirse a X.Y como esquema de versión con Y=0 → LTS.
Dejando a un lado la cadena de versión. Me gusta el nuevo plan de lanzamiento.
