Es imposible tener un proyecto en C# de más de 6 meses, y esperar que, al cabo de ese tiempo, pueda ser clonado y compilado. ¿Por qué? Por la versión del SDK (software development kit).
$ dotnet --version
8.0.110
$ dotnet --list-sdks
7.0.120
8.0.110
Pues eso, que como soy profesor les dejo a los alumnos una plantilla de proyecto con tests, para que tengan facilidades a la hora de completar los ejercicios de los exámenes. Tengo que actualizar esta plantilla cada vez que se inicia, pues Microsoft actualiza C# cada pocos meses... y además lo hace cambiando la versión de SDK, especialmente en su componente mayor, que es la que hace que una dll o un exe puedan ser cargados por la máquina virtual. En este momento, la versión es 9.0.101, es decir, componente mayor 9 y menor 0, parche número 101.
Según la documentación de .NET: "(...) se libera una nueva versión cada noviembre. Cada versión par, como .NET 6 y .NET 8 son LTS (Long-term supported). Las versiones LTS reciben soporte y actualizaciones durante tres años. Las versiones impares son de soporte estándar, obteniendo soporte durante 18 meses.
Este mecanimso de versionado es el mismo que en otro lenguaje de programación, y especialmente, máquina virtual; la que se conoce como JVM (Java Virtual Machine), que sigue el mismo esquema de numeración de versión `."
Pero, en realidad, Oracle y Microsoft son los extremos de un rango sobre cómo utilizar estos mecanismos de versionado. Como los rangos son muy aburridos, mejor pongo a las dos jugando a la cuerda.
Microsoft actualiza el número de versión con frecuencia, lo que obliga a actualizar los proyectos al mismo ritmo; mientras tanto Oracle... no ha cambiado el número mayor de versión... nunca. Inicialmente, no era Oracle el dueño de Java, sino Sun (Standford University Network). Cuando llegó el momento de liberar una segunda versión de Java, en lugar de otorgar el número de versión mayor número 2, lo que hace es asignar este 2 al número de versión menor, mientras el número de versión mayor se mantiene como 1. Así, potencialmente, un programa Java actual que no utilice las nuevas capacidades de Java, debería ser capaz de ser compilado y ejecutado con la primera versión de Java, la 1.1. Incluso, en las mismas circunstancias, podría intentarse ejecutar el jar o class resultante.
Bueno, en realidad, se podría ejecutar un jar compilado con una versión antigua, pero no al contrario, pues además de las versiones del JDK, existen también las versiones de formato de clases (class file version), de forma que se provocaría una UnsupportedClassVersionError.
Así que, al final, ninguno de los dos desarrolladores mantiene un sistema de versionado que realmente refleje la forma de trabajar de los SDK's... Quizás, podemos decir que Microsoft es más honesta, pero este modelo de trabajo no hace la vida de los desarrolladores más sencilla.
Top comments (0)