¿Cómo cambio la etiqueta de la paquete para su liberación estable?

Question

Debe etiquetar su código con un número de versión.

git tag -a 0.0.0

Eso declarará la primera versión estable. Si se preocupa por un número de versión All-Zero, puede comenzar con algo así como 0.0.1 si lo desea. Intenta seguir con versiones semánticas si puedes: http://semver.org. Después de eso, debe llevar al repositorio público, como git push --tags.

Tenga en cuenta que puede usar toda la variedad de etiquetas de estabilidad en sus etiquetas. Hay todo, desde Alpha, Beta, candidato de lanzamiento reconocido por el compositor. Ver http://getcomposer.org/doc/04-schema.md#version Para obtener información sobre cómo crear un número de versión.

Packagist luego escaneará su repositorio y procesará esa etiqueta, que es una versión "estable", y marcará su paquete en consecuencia (incluso con el número de versión 0.0.0 - El software 0.x no es diferente del software 24.X en términos de compositor /Packagist).

Editar 2016-07-14

Tenga en cuenta que los números de versión en versiones semánticas se manejan diferentes si comienzan con 0.x.y. Esto no afecta el etiquetado y la liberación de ninguna manera, pero afecta la forma en que los usuarios pueden seleccionar y actualizar su software lanzado. Cualquier software en el 0.x el rango se considera incompatible si lanza la próxima actualización menor 0.x+1. El operador de compositor Tilde ~ no será perturbado por esto: ~0.x (con cualquier número entero como x) se actualizará a la próxima versión menor. El operador de Caret se comportará diferente: ^0.x o ^0.x.y se quedará en el 0.x rango y no ir a ninguna 0.x+1.y liberar.

La mejor manera de contrarrestar esto sería comenzar con 1.x versiones y usar banderas de estabilidad para indicar posibles cambios. Puedes usar 1.0.0-alpha1 Como tu primer lanzamiento en lugar de 0.0.1, los lanzamientos posteriores pueden ser 1.0.0-alpha2 Para otra versión "inestable" (léase: API no terminado/estable), luego vaya a 1.0.0-beta1 para lanzamientos api-estables, pero internamente inacabados, luego 1.0.0-rc1 para posiblemente API-Stable, lanzamientos terminados durante la fase final de interrupción de errores, y luego 1.0.0 para el lanzamiento final. Más correcciones de errores serán 1.0.1 y arriba, las nuevas características serán 1.1.0, los cambios incompatibles de API serán 2.0.0. Tenga en cuenta que los primeros usuarios pueden usar ^1.0.0@beta Como requisito de su versión, y a medida que avanza el desarrollo, siempre obtendrá la actualización más reciente sin la necesidad de cambiar su requisito (a menos que rompa su API y forje las actualizaciones de esa manera). Esto nunca funcionará si vas al 0.x ruta y luego suelte el producto final como 1.0.0, porque tienes al menos la actualización incompatible obvia, salta a 1.0.

Es difícil decidir sin conocimiento futuro si un paquete demuestra ser útil y crea una base de usuarios feliz (que se beneficiará de un 1.0.0@alpha etiqueta de lanzamiento), o si es solo un experimento interesante que nadie está usando en la producción (también conocido como 0.x).

Mi preferencia personal por los paquetes privados internos es hacerlos 1.0 desde el comienzo. Tengo que lidiar con varios paquetes que comenzaron en 0.0.1 y son un poco desagradables cuando se actualizan porque son maduros, pero no pueden ir a 1.0 Debido a ese paso de versión incompatible, que implicaría mucho trabajo en paquetes secundarios.