Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El entorno de ejecución de .NET y el SDK de .NET agregan nuevas características a diferentes frecuencias. En general, el SDK se actualiza con más frecuencia que el tiempo de ejecución. En este artículo se explican el tiempo de ejecución y los números de versión del SDK.
.NET publica una nueva versión principal cada noviembre. Las versiones con números pares, como .NET 6 o .NET 8, son compatibles a largo plazo (LTS). Las versiones LTS obtienen soporte técnico y revisiones gratuitas durante tres años. Las versiones con números impares cuentan con soporte de término estándar. Las versiones de soporte técnico estándar obtienen soporte técnico gratuito y revisiones durante 18 meses.
Detalles de control de versiones
El entorno de ejecución de .NET utiliza un enfoque de versión mayor.menor.parche para el control de versiones que sigue el versionado semántico.
Sin embargo, el SDK de .NET no sigue el versionado semántico. El SDK de .NET se publica más rápido y sus números de versión deben comunicar tanto el entorno de ejecución alineado como las propias versiones secundarias y de revisión del SDK.
Las dos primeras posiciones del número de versión del SDK de .NET reflejan la versión del entorno de ejecución de .NET con el que se ha publicado. Cada versión del SDK puede crear aplicaciones para este entorno de ejecución o cualquier versión anterior.
La tercera posición del número de versión del SDK comunica tanto la versión secundaria como el número de revisión. La versión menor se multiplica por 100. Los dos dígitos finales representan el número de revisión. La versión secundaria 1 y la revisión 2 se representan con 102. Por ejemplo, esta es una posible secuencia de números de versión del SDK y tiempo de ejecución:
Cambio | Entorno de ejecución de .NET | SDK de .NET (*) | Notas |
---|---|---|---|
Versión inicial | 5.0.0 | 5.0.100 | Versión inicial. |
Revisión del SDK | 5.0.0 | 5.0.101 | El entorno de ejecución no cambió con esta revisión del SDK. La revisión del SDK incrementa el último dígito de la revisión. |
Entorno de ejecución y revisión del SDK | 5.0.1 | 5.0.102 | La revisión en tiempo de ejecución incrementa el número de revisión en tiempo de ejecución. La revisión del SDK incrementa el último dígito de la revisión. |
Cambio de características del SDK | 5.0.1 | 5.0.200 | La revisión en tiempo de ejecución no cambió. La nueva función del SDK aumenta el primer dígito en la revisión del SDK. |
Parche en tiempo de ejecución | 5.0.2 | 5.0.200 | La revisión en tiempo de ejecución incrementa el número de revisión en tiempo de ejecución. El SDK no cambia. |
En la tabla anterior puede ver varias directivas:
- Runtime y SDK comparten versiones principales y secundarias. Los dos primeros números de un SDK determinado y el tiempo de ejecución deben coincidir. Todos los ejemplos anteriores forman parte del flujo de versión de .NET 5.0.
- La versión de revisión del tiempo de ejecución solo se actualiza cuando se actualiza el tiempo de ejecución. El número de parche del SDK no se actualiza para un parche en tiempo de ejecución.
- La versión de parche del SDK solo se actualiza cuando se actualiza este. Es posible que una revisión en tiempo de ejecución no requiera una revisión del SDK.
NOTAS:
- Si el SDK tiene 10 actualizaciones de características antes de una actualización de características en tiempo de ejecución, los números de versión se acumulan en la serie 1000. La versión 5.0.1000 seguiría la versión 5.0.900. Esta situación no se espera que se produzca.
- No habrá 99 lanzamientos de parches sin un lanzamiento de nuevas características. Si una versión se acercase a este número, se forzaría una publicación de características.
Puede ver más detalles en la propuesta inicial en el repositorio dotnet/designs .
Control de versiones semántico
En cierto modo, el entorno de ejecución de .NET Core el Versionamiento Semántico (SemVer), que adopta el uso del esquema de control de versiones MAJOR.MINOR.PATCH
y emplea las distintas partes del número de versión para describir el grado y el tipo de cambio.
MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]
Los elementos opcionales PRERELEASE
y BUILDNUMBER
nunca forman parte de las versiones admitidas y solo existen en compilaciones nocturnas, compilaciones locales a partir de destinos de origen y versiones preliminares no admitidas.
Cambios en el número de versión de ejecución
MAJOR
se incrementa una vez al año y puede contener:- Cambios significativos en el producto o en una nueva dirección del producto.
- La API introdujo cambios importantes. Hay un nivel de aceptación de cambios importantes elevado.
- Se adopta una versión más reciente
MAJOR
de una dependencia existente.
Las versiones principales se producen una vez al año y las versiones con números pares son versiones de soporte a largo plazo (LTS). La primera versión de LTS que usa este esquema de control de versiones es .NET 6. La versión más reciente que no es LTS es .NET 9.
MINOR
se incrementa cuando:- Se agrega un área expuesta de API pública.
- Se agrega un nuevo comportamiento.
- Se adopta una versión más reciente
MINOR
de una dependencia existente. - Se introduce una nueva dependencia.
PATCH
se incrementa cuando:- Se realizan correcciones de errores.
- Se agrega compatibilidad con una plataforma más reciente.
- Se adopta una versión más reciente
PATCH
de una dependencia existente. - Cualquier otro cambio no se ajusta a uno de los casos anteriores.
Cuando hay varios cambios, se incrementa el elemento más alto afectado por los cambios individuales y los siguientes se restablecen a cero. Por ejemplo, cuando MAJOR
se incrementa, MINOR.PATCH
se restablece a cero. Cuando MINOR
se incrementa, PATCH
se restablece a cero mientras MAJOR
permanece igual.
Números de versión en nombres de archivo
Los archivos descargados para .NET llevan la versión, por ejemplo, dotnet-sdk-5.0.301-win-x64.exe
.
Versiones preliminares
Las versiones preliminares tienen un -preview.[number].[build]
anexado al número de versión. Por ejemplo: 6.0.0-preview.5.21302.13
.
Versiones de mantenimiento
Después del lanzamiento de una versión, las ramas de la versión generalmente dejan de producir compilaciones diarias y, en su lugar, comienzan a generar compilaciones de mantenimiento. Las versiones de mantenimiento tienen un -servicing-[number]
anexado a la versión. Por ejemplo: 5.0.1-servicing-006924
.
Compatibilidad con el entorno de ejecución de .NET
El entorno de ejecución de .NET mantiene un alto nivel de compatibilidad entre versiones. Las aplicaciones .NET deben seguir funcionando después de actualizar a una nueva versión principal de .NET Runtime.
Cada versión principal de .NET Runtime contiene cambios importantes, cuidadosamente examinados y documentados. Los cambios importantes documentados no son el único origen de problemas que pueden afectar a una aplicación después de la actualización. Por ejemplo, una mejora del rendimiento en el entorno de ejecución de .NET (que no se considera un cambio importante) puede exponer errores de subprocesos de la aplicación latentes que hacen que la aplicación no funcione en esa versión. Se espera que las aplicaciones de gran tamaño requieran algunas correcciones después de actualizar a una nueva versión principal de .NET Runtime.
De forma predeterminada, las aplicaciones .NET están configuradas para ejecutarse en una versión principal de .NET Runtime determinada, por lo que se recomienda volver a compilar la aplicación para que se ejecute en una nueva versión principal de .NET Runtime. A continuación, vuelva a probar la aplicación después de actualizar para identificar los problemas.
Supongamos que la actualización a través de la recompilación de aplicaciones no es factible. En ese caso, el entorno de ejecución de .NET proporciona una configuración adicional para permitir que una aplicación se ejecute en una versión de runtime de .NET principal superior a la versión para la que se compiló. Esta configuración no cambia los riesgos implicados en la actualización de la aplicación a una versión de .NET Runtime principal más alta y sigue siendo necesario volver a probar la aplicación después de la actualización.
.NET Runtime admite la carga de bibliotecas destinadas a versiones anteriores de .NET Runtime. Una aplicación que se actualiza a una versión más reciente de .NET Runtime principal puede hacer referencia a bibliotecas y paquetes NuGet que tienen como destino versiones anteriores de .NET Runtime. No es necesario actualizar simultáneamente la versión de tiempo de ejecución de destino de todas las bibliotecas y paquetes NuGet a los que hace referencia la aplicación.