I have been using git flow for a couple of months and it has worked very well. I would like to automate the "bump version" operation.
The project is PHP and the footer.php has a token to replace with the current release tag. I am certain that with some awk'ing of git log and the PHP file everything should work out, but I assume someone has done this before...
Any ideas?
You could use the semver gem, which adds a file .semver to the root of your git repo. Semantic version numbers are a recommendation for having structured/consistent/meaningful version numbers, the gem just makes it easy to implement.
So, all you'd need to do is add:
semver inc major|minor|patch
into your workflow (manually or scripted) so that the .semver gets updated during a release.
If you don't want the ruby dependency, semver is pretty simple, so a bit of sed experimentation will likely yield a working solution.
There's also bumpversion (more info at https://github.com/peritus/bumpversion) that aims to replace that sed magic.
Install with pip install bumpversion, tell it which files contain your version number and whether you want to commit and tag that. It's also highly configurable (with semantic versioning as default), so you can add a declarative config file of how to bump versions for this software project to your vcs of choice and others can also bump versions.
In my forked project of git-flow I actually implemented hooks and filters, a request that many made in the original project but so far has not been implemented. With those you can automatically update version numbers in your project. The forked project can be found here https://github.com/petervanderdoes/gitflow
For some Bash scripts on version bumping you can check out two gists I created https://gist.github.com/2877083 or https://gist.github.com/2878492
Semver webpage states:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Gitflow uses a naming convention for branches, bug fixes live on branches prefixed with hotfix/ and new features are prefixed with feature/.
When any branch of this type is merged into release branch this causes the PATCH to increase. If a feature has been merged the MINOR field should be increased.
Given a specific revision, you should be able to figure of if either of the branches have been merged and which field to bump.
The hard part is figuring out a breaking change. In the past I've considered using reflection on compiled code to determine if the API has changed, however, I figure it would be much easier to perhaps just use a keyword in commit messages to designate breaking changes.
You can also take a look at my repo for bumpversion its currently made for python setup files which can be modified Using-bumpversion-package
Here is the code we use to increment the version number in constants.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
If I understand your 'bump version' operation correctly, then you mean increasing the version number in an arbitrary number of files once you started a release with git flow release start x.x.x, where the version is also represented within the git tag.
Since the original git-flow from Driessen was discontinued, the unofficial successor seems to be Peter van der Does gitflow-avh (https://github.com/petervanderdoes/gitflow-avh/), which contains a great number of git flow hooks. See https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks for a complete list.
I did version bumping on post-flow-release-start with this little 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
It is a bit rigid, because the two files are hardcoded (README.md and package.json). You could do a search for the old version from the last tag and then repleace it for all configured files within a loop.
Caveats:
OSX requires a suffix for sed -i, you can use empty quotes though. Also, the extended regex param for sed is named differently on Linux.
You can automate the version bumping every commit. Here you can find it done using the shell script and the built-in git hook: https://github.com/addonszz/Galileo/tree/develop/githooks
The shell scrip to run is: https://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh
The problem about automate every thing is how to know whether you are updating the Major, Minor, Patch or Build, when you are committing everything.
I mean, for build you could automate every development branch commit, as done in the above link.
The patch, you can hook every git flow hotfix finish. The above link just lacks to hook the hotfix finish to increment the patch version running:
./githooks/updateVersion.sh patch
But the minor and major there is no trick, they are all done within the feature finish release.
I found a solution to hooking the pre-hotfix-commits, it is on the question: How to pre-hook the gitflow hotfix finish?
