Ir al contenido principal

base-cli-contractkit-dappkit-utils

title: Proceso de lanzamiento de Celo para CeloCLI y ContractKit descripción: Detalles del proceso de lanzamiento para actualizar CeloCLI y ContractKit en la plataforma de Celo.

Proceso de liberación para CeloCLI y ContractKit

Detalles del proceso de lanzamiento para actualizar CeloCLI y ContractKit en la plataforma Celo.

Versionamiento​

Utiliza el esquema estándar de versionado semántico MAJOR.MINOR.PATCH descrito en semver.org.

Se pueden esperar nuevas versiones de la siguiente manera:

  • Versiones mayores: aproximadamente una vez al año
  • Versiones menores: aproximadamente 8 veces al año
  • Versiones de parche: según sea necesario

Las compilaciones de desarrollo se identificarán como: x.y.z-dev, y se publicarán como x.y.z cuando sean estables.

Identificando lanzamientos​

NPM​

Puede encontrar los paquetes npm en los siguientes lugares:

Etiquetas de Github​

Para identificar los commits incluidos en una versión concreta y ver qué nuevas funciones se han añadido o qué errores se han corregido, consulte las notas de la versión en el monorepo. También para mantener un registro de las continuas actualizaciones de las versiones estable y dev de los paquetes, cada paquete tiene un archivo CHANGELOG.md: Celocli y Contractkit. Todas las versiones deben etiquetarse con el número de versión, por ejemplo contractkit-vX.Y.Z. Cada versión debe incluir un resumen de su contenido, con enlaces a pull requests e incidencias y una descripción detallada de los cambios más destacados.

Comunicación​

Las actualizaciones de los paquetes se notificarán a la comunidad a través de los siguientes canales:

Para todas las versiones:

  • El archivo CHANGELOG.md de cada paquete, como se ha mencionado anteriormente
  • Página de versiones de Github, como ya se ha mencionado
  • Discord: #developer-chat, #mainnet, and #sdk

Para versiones mayores:

Proceso de construcción​

Los paquetes se publican siguiendo las instrucciones aquí.

Probando​

Todas las compilaciones de estos paquetes se prueban automáticamente en CI para comprobar su rendimiento y compatibilidad con versiones anteriores. Cualquier regresión en estas pruebas debe considerarse un bloqueo para una versión. Se espera que las versiones menores y mayores pasen por rondas adicionales de pruebas manuales según sea necesario para verificar el comportamiento en condiciones de estrés.

peligro

Trabajo en progreso

Proceso de promoción​

  • Para un lanzamiento de parche: El primer paso de este proceso debe ser un commit que cambie el número de versión codificado en el código fuente de x.y.z-dev a x.y.z+1-dev y el paso final debe cambiar el número de versión publicado de x.y.z-1 a x.y.z.
  • Para versiones menores, se debe seguir el mismo proceso, excepto que el valor y se incrementaría, y el valor z pasaría a ser 0.
  • Para versiones mayores, se debe seguir el mismo proceso, excepto que el valor x se incrementaría, y los valores y y z pasarían a ser 0.

Sólo un commit debería tener una etiqueta non-dev en cualquier número de versión. Cuando se cree ese commit, se añadirá una etiqueta junto con las notas de la versión. Una vez publicada la etiqueta, no debe reutilizarse para ninguna otra publicación o modificación.

Parches de emergencia​

Los errores que afectan a la seguridad, la estabilidad o la funcionalidad básica de la red pueden tener que publicarse fuera del ciclo de publicación estándar. En este caso, debe crearse una versión de parche de emergencia sobre todas las versiones menores compatibles que contenga el cambio mínimo y la prueba correspondiente para la corrección. También se publicará un parche retro de emergencia, que incluirá información como por qué era necesario el parche y qué cambios de código incluye.

Revelación de vulnerabilidades​

Las vulnerabilidades de cualquiera de estas versiones deben revelarse de acuerdo con la política de seguridad.

Dependencias​

  • @celo/mobile - Dappkit depende de esto
  • Celocli
  • Todos los paquetes bajo la carpeta "SDK" -- Estos dependen unos de otros bastante, así que comprueba tres veces que estos paquetes no se han visto afectados por un cambio en otro.

Dependientes​

  • Celocli
  • Todos los paquetes en la carpeta "SDK"