He visto muchos proyectos utilizando v1.2.3como convención de nomenclatura para etiquetas en git. También he visto algún uso 1.2.3. ¿Existe un estilo oficialmente aprobado, o hay algún buen argumento para usarlo?
229
La versión 1.0.0 de Semantic Versioning , de Tom Preston-Werner de GitHub fame, tenía una subespecificación que abordaba esto:
Especificación de etiquetado (SemVerTag)
Esta subespecificación DEBERÍA utilizarse si utiliza un sistema de control de versiones (Git, Mercurial, SVN, etc.) para almacenar su código. El uso de este sistema permite que las herramientas automatizadas inspeccionen su paquete y determinen el cumplimiento de SemVer y las versiones publicadas.
- Al etiquetar versiones en un sistema de control de versiones, la etiqueta para una versión DEBE ser "vX.YZ", por ejemplo, "v3.1.0" .
Sin embargo, después de la discusión, esto se eliminó y ya no está presente en la última versión de la especificación SemVer (2.0.0 en el momento de la redacción). Un hilo de discusión posterior en el mismo lugar entró en mayor profundidad y dio como resultado un nuevo ¿Es "v1.2.3" una versión semántica? se agrega a las preguntas frecuentes en la mastersucursal de SemVer , aunque en el momento de la redacción (más de 2 años después) este cambio todavía no está presente en la especificación oficialmente publicada.
vdebería estar allí sin embargo.
Parece que hay dos convenciones dominantes (suponiendo que también cumpla con algún estándar razonable para numerar los lanzamientos mismos):
v1.2.31.2.3Las ventajas v1.2.3son que la documentación de Git (y también la documentación de Mercurial) usa ese formato en sus ejemplos, y que varias "autoridades" como el kernel de Linux y Git lo usan. (La versión semántica mencionada solía usarlo, pero ya no lo hace).
Las ventajas 1.2.3son que gitweb o GitHub pueden ofrecer automáticamente una descarga tarball o zip del formulario packagename-$tag.tar.gz(y creo que está bastante establecido que no se debe nombrar un tarball package-v1.2.3.tar.gz). Alternativamente, puede usar git describedirectamente para generar números de versión de tarball. Para proyectos livianos sin un proceso de lanzamiento formal, estas posibilidades pueden ser bastante convenientes. También debe tenerse en cuenta que el control de versiones semántico no es el único estándar universalmente aceptado para la numeración de versiones. Y proyectos notables como GNOME, así como innumerables proyectos, usan el 1.2.3nombre de la etiqueta.
Creo que probablemente sea demasiado tarde para consolidar estas posiciones. Como siempre, sea consistente y tenga sentido.
Actualización: como se menciona en este comentario, GitHub ahora ofrece un nombre tarball con la 'v' despojada de la etiqueta.
v.
La razón de la 'v' precedente es histórica. SCCS anteriores (cvs, rcs) no podían distinguir entre un identificador de etiqueta y un número de revisión. Los identificadores de etiqueta se restringieron para que no comenzaran con un valor numérico para poder detectar los números de revisión.
No que yo sepa.
Pero Git no permitirá una etiqueta y una rama del mismo nombre al mismo tiempo, por lo que si tiene una rama " 1.1" para 1.1trabajos, no coloque una etiqueta " 1.1", use por ejemplo " v1.1"
Los nuevos administradores de paquetes aconsejan etiquetar versiones sin prefijo v(como compositor para proyectos PHP)
SemVer 2.0 no tiene nada sobre la especificación de etiqueta. Se hace intencionalmente debido a evitar conflictos. Sin embargo, se recomienda agregar un prefijo ven la documentación y referencias de texto. Como formato de ejemplo en v1.0.4lugar de completo version 1.0.4o ver. 1.0.4es bastante detallado y elegante en la documentación.
Utilizamos ramas y etiquetas para el trabajo específico de la versión seguido de la versión real, respectivamente:
o---o-----o---o---o--- ... master
\ / /
\ / /
o-------o--- ... 1.6 branch
Cada desarrollador toma una decisión mental sobre si el trabajo que está a punto de realizar es aplicable solo para masterizar o si también es relevante para la rama. Puede ver que los cambios que se realizan en la rama se fusionan en el maestro, pero algunos cambios en el maestro nunca irán a la rama (es decir, aquellos que no están destinados a la versión 1.6, en este ejemplo).
Cuando estamos listos para lanzar, lo etiquetamos y luego lo fusionamos por última vez, y nombramos la etiqueta con el mismo nombre que la rama, pero con un identificador adicional sobre qué versión en particular es, por ejemplo, "1.6-release" o "1.6-beta" o "1.6-rc2", etc.
... ------o---o---o--o---o--- ... master
/ /
/ /
... ---o------(*)--- ... 1.6 branch
1.6-release
No conozco ningún estándar. Simplemente elijo los nombres de mis etiquetas para que pueda pegar un
VERSION = `git describe --tags`
en mis scripts de compilación. Entonces, la convención de nomenclatura de etiquetas en realidad depende de la convención de nomenclatura de versión del proyecto.
No hay una mejor práctica que yo sepa. Aquí hay algunos enlaces:
En general, control de versiones ( 0.0.1, v0.2.1, ...) tal vez de la mano con algunos de seguimiento de problemas podría considerarse un enfoque plausible. (... aunque generalmente uso vnombres de etiquetas prefijadas ... vea también la respuesta @VonC)
v/ya que agrupa las etiquetas en un espacio de nombres. 2. idealmente, una etiqueta también debe contener un acrónimo que identifique de forma exclusiva la aplicación. por ejv/myapp/1.0. Esto facilita la fusión del repositorio de git: en caso de que las aplicaciones se fusionen, las etiquetas no colisionarán en el espacio de nombres de la etiqueta.