paper - Buscando una forma de automatizar la "versión funcional" con git flow
install git flow en mac (8)
He estado usando git flow por un par de meses y ha funcionado muy bien. Me gustaría automatizar la operación "bump version".
El proyecto es PHP y el footer.php tiene un token para reemplazar con la etiqueta de la versión actual. Estoy seguro de que con un poco de información sobre el registro de git y el archivo PHP todo debería funcionar, pero supongo que alguien lo ha hecho antes ...
¿Algunas ideas?
Aquí está el código que usamos para incrementar el número de versión en constantes.h:
constants=''../Include/constants.h''
# Get the current build number
currentbuild=`grep PRODUCT_BUILD $constants|sed ''s/[^0-9]//g''`
currentversion=`grep PRODUCT_VERSION $constants|sed ''s/[^.0-9]//g''`
echo "currentbuild=$currentbuild and currentversion=$currentversion"
newver=$((1+$currentbuild))
# Update the build number on-disk:
cp $constants /tmp/constants
if sed -e "/PRODUCT_BUILD/ s/[0-9][0-9]*/${newver}/" < /tmp/constants > $constants
then
echo "Updated build number from $currentversion.$currentbuild to $currentversion.$newver."
cd ../Include
# Check it into version control
svn ci -m "updated build number to ${currentversion}.${newver} for $buildid in $buildroot"
else
echo "There was a problem updating $constants to build $newver"
fi
En mi proyecto bifurcado de git-flow implementé en realidad ganchos y filtros, una solicitud que muchos hicieron en el proyecto original pero que hasta ahora no se ha implementado. Con esos puedes actualizar automáticamente los números de versión en tu proyecto. El proyecto bifurcado se puede encontrar aquí https://github.com/petervanderdoes/gitflow
Para algunos scripts de Bash en el bump de la versión, puedes ver dos gists que creé https://gist.github.com/2877083 o https://gist.github.com/2878492
La página web de Semver dice:
Dado un número de versión MAJOR.MINOR.PATCH, incremente el:
- Versión importante cuando haces cambios de API incompatibles,
- Versión MENOR cuando agrega funcionalidad de una manera compatible con versiones anteriores, y
- Versión de PATCH cuando haces correcciones de errores compatibles con versiones anteriores.
Las etiquetas adicionales para los metadatos de prelanzamiento y construcción están disponibles como extensiones para el formato MAJOR.MINOR.PATCH.
Gitflow usa una convención de nomenclatura para las sucursales, las correcciones de errores en vivo en las sucursales con el prefijo hotfix/ y las nuevas características tienen el prefijo con la feature/ .
Cuando cualquier rama de este tipo se combina en la rama de lanzamiento, esto hace que el PATCH aumente. Si una característica se ha fusionado, el campo MENOR debe aumentarse.
Dada una revisión específica, debería poder determinar si alguna de las ramas se ha fusionado y qué campo debe golpear.
La parte difícil es descubrir un cambio importante. En el pasado, he considerado utilizar la reflexión en el código compilado para determinar si la API ha cambiado, sin embargo, creo que sería mucho más fácil, tal vez, simplemente utilizar una palabra clave en los mensajes de confirmación para designar cambios de última hora.
Puede automatizar la versión bump cada compromiso. Aquí puede encontrarlo con el script de shell y el gancho de git incorporado: https://github.com/addonszz/Galileo/tree/develop/githooks
El script de shell que se ejecutará es: https://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh
El problema de automatizar cada cosa es cómo saber si está actualizando Major, Minor, Patch o Build, cuando está comprometiendo todo.
Quiero decir, para la compilación usted podría automatizar cada compromiso de rama de desarrollo, como se hace en el enlace anterior.
El parche, puede enganchar cada acabado de git flow hotfix. Falta el enlace anterior para enganchar el acabado de la revisión para incrementar la versión del parche que se ejecuta: ./githooks/updateVersion.sh patch
Pero el menor y el mayor no hay truco, todos se realizan dentro del lanzamiento de la característica final.
Obs
Encontré una solución para enganchar el pre-hotfix-commit, está en la pregunta: ¿Cómo enganchar el acabado de la revisión de gitflow?
Si entiendo su operación de ''versión mejor'' correctamente, entonces quiere decir aumentar el número de versión en un número arbitrario de archivos una vez que inició una versión con git flow release start xxx , donde la versión también está representada dentro de la etiqueta git.
Desde que se suspendió el flujo de git original de Driessen, el sucesor no oficial parece ser Peter van der Does gitflow-avh ( https://github.com/petervanderdoes/gitflow-avh/ ), que contiene una gran cantidad de ganchos de flujo de git . Vea https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks para obtener una lista completa.
Hice la versión bump en post-flow-release-start con este pequeño script:
VERSION=$1
# Get rid of version prefix
STRIPPED_VERSION=`echo $VERSION | cut -d''v'' -f 2`
sed -i '''' -E "s/^([ |#|[:alpha:]]*)/[.*/]$//1[$STRIPPED_VERSION]/1" ./README.md
sed -i '''' -E "s/^([/t| ]*/"version/": )/".*/"//1/"$STRIPPED_VERSION/"/1" ./package.json
git commit -a -m "version $STRIPPED_VERSION"
exit 0
Es un poco rígido, porque los dos archivos están codificados (README.md y package.json). Puede hacer una búsqueda de la versión anterior de la última etiqueta y luego repostarla para todos los archivos configurados dentro de un bucle.
Advertencias:
OSX requiere un sufijo para sed -i , aunque puedes usar comillas vacías. Además, el parámetro regex extendido para sed se nombra de manera diferente en Linux.
También hay bumpversion (más información en bumpversion ) que apunta a reemplazar esa magia sed.
Instale con pip install bumpversion , dígale qué archivos contienen su número de versión y si desea confirmar y etiquetar eso. También es altamente configurable (con la versión semántica por defecto), por lo que puede agregar un archivo de configuración declarativo de cómo cargar las versiones para este proyecto de software a su vcs de elección y otros también pueden hacerlo.
También puede echar un vistazo a mi repositorio para bumpversion que está hecho actualmente para los archivos de configuración de Python que pueden modificarse Using-bumpversion-package
Podría usar la gema semver , que agrega un archivo .semver a la raíz de su repositorio git. Los números de versión semánticos son una recomendación para tener números de versión estructurados / consistentes / significativos, la gema simplemente hace que sea fácil de implementar.
Entonces, todo lo que necesitas hacer es agregar:
semver inc major|minor|patch
en su flujo de trabajo (manualmente o con secuencias de comandos) para que el .semver se actualice durante una versión.
Si no desea la dependencia de ruby, semver es bastante simple, por lo que un poco de experimentación con sed probablemente proporcionará una solución de trabajo.