logo cosasdedevs
Cómo funciona el sistema de versiones de Composer

Cómo funciona el sistema de versiones de Composer



My Profile
May 18, 2022

👋 ¡Hola! ¿Alguna has abierto el archivo composer.json y junto a las versiones de las librerías te aparece ^ o ~ el cual no te queda claro su funcionamiento? Pues bien, esto lo solucionamos hoy 💪. En este tutorial voy a explicarte cómo funciona el sistema de versiones de Composer.

Relación entre Composer y los tags de GIT 🤔

En GIT, aparte de ramas, podemos crear tags en cada uno de nuestros repositorios. Estos tags, etiquetan puntos específicos del proyecto y se utilizan normalmente para marcar versiones de lanzamiento. Estos serían algunos ejemplos de tags que he encontrado en la documentación de Composer:

v1.0
v1.0.1
v1.0.2
v1.1-BETA
v1.1-RC1
v1.1-RC2
v1.1
v1.1.1
v2.0-BETA
v2.0-RC1
v2.0
v2.0.1
v2.0.2

Como puedes observar, se añade "v" al principio que significa versión, después continua una secuencia numérica que indica la versión que está separada por puntos y cada uno de ellos indica una cosa.

Ejemplo: 1.5.14

El primer número (1) se le conoce como versión mayor y nos indica la versión principal de software. Un incremento de numeración aquí lo encontramos cuando hacemos grandes cambios que afectan al comportamiento de nuestra librería.

El segundo número (5) se le conoce como versión menor e indica nuevas funcionalidades.

El tercer número (14) se le conoce como revisión o parche e indica que se hizo alguna corrección del código por un fallo. Además, este puede ser opcional.

Por último, opcionalmente, puedes añadir un guion "-" y el nivel de estabilidad (dev, alpha, beta, RC, stable).

Pues bien, cuando queremos subir un paquete al repositorio de Composer (https://packagist.org/), este necesita que le indiquemos un repositorio de GIT (también funciona con otros tipos como SVN). Al hacerlo, leerá los tags y gracias a eso, cuando queramos descargar un paquete, tendremos la opción indicar que versión de la librería queremos obtener.

Esto nos puede venir bien, por ejemplo, en casos en los que la última versión del paquete no sea compatible con nuestra versión de PHP o si un paquete depende de otros paquetes que trabajen con las versiones con las que sean compatibles.

Formas de indicar versiones 💡

Explicado esto, ahora si te voy a contar las distintas formas de indicar una versión y ya de paso te explico el funcionamiento del ^ y ~ (no me olvido eh 😅).

Versión exacta

Cuando queremos indicar una versión en concreto de un paquete, debemos añadir la versión al completo. El problema de esto, es que si otras dependencias requieren otra versión de esta librería, la instalación fallará.

Ejemplo: 1.5.2

Rangos de versiones

Cuando queremos indicar un rango de versiones, podemos utilizar los operadores de comparación (>, >=, <, <=, !=). Si queremos emplear múltiples rangos, podemos separarlos por espacios o comas, los cuales actuarán como el operador AND. En el caso de querer elegir entre una versión y otra, podemos usar || el cual funcionará como el operador OR. Cabe indicar que entre AND y OR prevalecerá el primero.

Ejemplos:

>=1.0 <=1.2
>1.5
<1.4.2
>=1.0 <1.1 || >=1.2
>=1.4

Rangos de versiones con guion

También podemos utilizar un guion entre dos versiones para poder obtener una librería en ese rango:

Ejemplos:

1.0.0 - 2.1.0 equivale a >=1.0.0 <=2.1.0
1.0 - 2.0 equivale a >=1.0.0 <2.1

Rangos de versiones con asterisco

El asterisco reemplaza a cualquier número que sustituyamos en una versión. Si por ejemplo escribimos 1.0.* esto equivaldría a >=1.0 <1.1

Rangos de versiones con  ~

Este operador es mejor explicarlo con un ejemplo, ~1.2 equivale a >=1.2 <2.0.0,  mientras que ~1.2.3 equivale a >=1.2.3 <1.3.0.

En el primer ejemplo, en el que indicamos la versión mayor y menor, equivale a todo lo que empieza en esa versión hasta la versión 2.0.0.

En el segundo ejemplo, tenemos la versión mayor, versión menor y el parche. Como veis, en este caso, al añadir el parche, el rango correspondería hasta la siguiente versión menor (1.3.0).

Rangos de versiones con ^

Es similar al anterior, pero en este caso, aunque definamos la versión mayor, menor y parche, el rango se extenderá hasta justo antes del cambio a la versión mayor.

Por ejemplo, valiéndonos del caso anterior, si escribimos ^1.2.3, equivale a >=1.2.3 <2.0.0.

Eso si, en el caso de versiones por debajo de 1.0 sí que hay un cambio y es que en este caso ^0.3, el rango será hasta la siguiente mínima versión, lo que equivale a >=0.3.0 <0.4.0.

En el caso de añadir también el parche ^0.0.3, el rango equivale hasta el siguiente parche >=0.0.3 <0.0.4.

Pues ya está, fácil ¿Verdad? Mi recomendación es que os guardéis este tutorial en favoritos porque lo vais a tener que revisar más de una vez (a mí me pasa).

Parte de este tutorial es una traducción de la documentación de Composer, os dejo en link por si queréis echarle un vistazo 👇

https://getcomposer.org/doc/articles/versions.md

Para finalizar, por si te has quedado con ganas de saber más cositas de Composer, te dejo este tutorial  en el que explico como configurar un proyecto con Composer.

Espero que este post te ayude y como siempre, te recomiendo seguirme en Twitter para estar al tanto de los nuevo contenido. Ahora también puedes seguirme en Instagram donde estoy subiendo tips, tutoriales en vídeo e información sobre herramientas para developers.

Por último os dejo mi guía para aprender a trabajar con APIs donde explico todo el funcionamiento de una API, el protocolo HTTP y veremos como construir una API con arquitectura REST.

Nos leemos 👋.

1280 vistas

🐍 Sígueme en Twitter

Si te gusta el contenido que subo y no quieres perderte nada, sígueme en Twitter y te avisaré cada vez que cree contenido nuevo 💪
Luego ¡Te sigo!

Nos tomamos en serio tu privacidad

Utilizamos cookies propias y de terceros para recopilar y analizar datos sobre la interacción de los usuarios con cosasdedevs.com. Ver política de cookies.