¿Cómo se aplica el control de versiones semántico a los programas sin API?

En http://semver.org/, que en mi opinión parece ser la convención más utilizada en el control de versiones, se recomienda aumentar el número de versión principal cuando se introduce un cambio que rompe / modifica la API.

Sin embargo, hay dos escenarios relacionados que no veo cómo aplicar esta directriz:

1. ¿Qué pasa si mi código no ofrece ninguna API? ¿Cómo debo versionar mi código?
2. ¿Qué sucede si mi código comienza a ofrecer una API en una etapa tardía de su desarrollo?

Semver está principalmente preocupado por el control de versiones de bibliotecas y paquetes de una manera que evita el infierno de dependencia, en sus diversas encarnaciones. Sin embargo, la idea detrás de Semver puede extenderse a todo tipo de programas: cualquier pieza de código tiene algún tipo de interfaz de usuario, o es bastante inútil.

• Una biblioteca de programación o servicio web tiene una API.
• El software de consumo puede tener una GUI.
• Los programas de línea de comando tienen un conjunto de interruptores y opciones.
• Los archivos de configuración también son una interfaz de usuario.

Usando el ejemplo de software de consumo, como un procesador de textos:

• Aumente el número de parche cuando envíe una corrección de error, por ejemplo: " error corregido donde la aplicación siempre falla a las 00:00 PM los martes ".
• Incremente el número de versión menor al agregar una nueva función, por ejemplo: " soporte agregado para texto subrayado ".
• Incremente la versión principal cuando revise significativamente la interfaz de usuario o reescriba todas las partes internas. Por ejemplo: “Las barras de herramientas usan demasiado estado de pantalla. La interfaz de usuario ahora se proporciona solo a través de gestos táctiles ”, tal cambio interrumpiría los flujos de trabajo existentes.

Sin embargo, muchos problemas que Semver intenta resolver no existen fuera del área de gestión de dependencias. En las aplicaciones de consumo, la versión no es solo una versión, sino también un activo de marketing.

• Firefox y Chrome lanzan nuevas versiones con relativa frecuencia e incrementan su número de versión principal en cada versión. Esto da como resultado números de versión ridículamente altos (ambos están actualmente en sus 30 años). Un navegador con un número de versión superior debe ser simplemente mejor que un navegador con un número de versión inferior, ¿verdad?

• El número de versión principal del sistema operativo OS X de Apple se ha convertido en parte del nombre (X es 10 en números romanos), lo que hace que el número de versión menor sea el número de versión principal efectivo.

• El sistema operativo Ubuntu utiliza un esquema de versiones de year.month.patchlevel. Esto hace que sea fácil recordar la antigüedad de su sistema operativo, pero hace que sea mucho más difícil determinar qué versiones son compatibles y cuánto tiempo dura el soporte para cada versión.

• El kernel de Linux superó el número de versión de 2.6.39 a 3.0.0, porque se 39estaba volviendo un poco grande y para conmemorar el 20 aniversario de Linux.

• El legendario sistema de composición tipográfica TeX de Donald Knuth utiliza un número de versión que, a partir de la versión 3, converge a π agregando otro dígito en cada versión: 3.14159265…. Esto significa cómo el sistema se está acercando a la perfección. Del mismo modo, el sistema Metafont converge a e : 2.7182818 ...

Por lo tanto, muchas aplicaciones no son bien atendidas por Semver. Elija un esquema de versiones que sea bueno para sus usuarios (independientemente de si estos usuarios son programadores o consumidores) y manténgalo consistente.