En cualquier tipo de software las versiones son algo familiar. La primera versión de un proyecto es normalmente denotada como 1.0.0, la versión beta cuando un proyecto es nuevo, o una versión menor cuando se arregla algún error o existe una nueva feature.
Al instalar un plugin de WordPress o una librería de NPM, cada vez que cambiamos una versión algo se arregla o algo se añade y la forma sistematica para describir esos cambios es a través de “semantic versioning”.
Semantic versiong es la forma como denotamos el cambio de un proyecto.
Implementar semantic versioning es bastante sencillo y la complejidad viene con la personalización que necesitemos, veamos la que más utilizo.
Intalemos el paquete para hacer semantic release
yarn add --dev semantic-release
Agregemos la configuración a package.json
"release": { "verifyConditions": [ "@semantic-release/github" ], "publish": [ "@semantic-release/github" ], "githubUrl": "https://api.github.com" }
Donde en este ejemplo, es de un proyecto en el que no voy a publicar el proyecto en NPM. Este solamente creará un tag y un release en github.
Si en caso quisiera que también el proyecto se publicara en el registry, la configuración sería algo así.
En este ejemplo, usaremos Travis CI, y la configuración necesaria es una variable de entorno GH_TOKEN
, que puedes obtener en el área personal de tokens y luego agregar en tu proyecto.
En caso necesites publicar el projecto a NPM registry, debes agregar NPM_TOKEN
.
Luego debemos hacer saber a nuetro CI que deseamos publicar una nueva versión en el build, agregando la configuración en Travis (.travis.yml):
language: node_js node_js: - node cache: npm script: - npm run build after_success: - npm run semantic-release notifications: email: false
Cada vez que se haga un push a master en tu proyecto (merge o commit), este hará un nuevo release en GitHub. En caso utilizas yarn
, puedes cambiarlo y funcionará de igual forma.
last-release-github
Las nuevas versiones de tu proyecto pueden ser descritas por los commits, y siguen el formato de Angular.
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
Los tipos de commits más comunes son:
Sin embargo existen más.
Al principio puede ser tedioso y una tarea mental hacer commits con este formato, haciendo que no se genere una nueva versión de nuestro proyecto. Para esto existen herramientas que enforzan y facilitan la creación de commits con este formato.
Instalemos el commit linter.
yarn add --dev husky @commitlint/config-conventional @commitlint/cli
Configuremos el git hook relacionado.
{ "scripts": { "commitmsg": "commitlint -e $GIT_PARAMS" } }
Y luego, este verificará que el commit tenga el formato necesario para hacer semantic release.
Existen otras herramientas como Commitizen que tienen el mismo objetivo.
Crear releases de nuestros proyectos ayudan a poder saber como el proyecto ha evolucionado y el estado del mismo.
Además de proveer una forma común de describir el tipo de cambio que nuestro proyecto tiene durante el tiempo, e informar a los consumidores del mismo.
📚
2 functions that made my components responsive at The practical dev.
From WordPress to static site—the Contentful way at Contentful's blog.
Coders Cut: The conversational article at Typeform's blog.
📹
The journey of a new interface at Frontend Connect.
Jepser Bernardino: Sitios web estáticos con WordPress y React at WordPress.tv.
Jepser Bernardino: Styled components ¿Por qué css en javascript? at WordPress.tv.