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:
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.
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
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: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 forsed
is named differently on Linux.Semver webpage states:
Gitflow uses a naming convention for branches, bug fixes live on branches prefixed with
hotfix/
and new features are prefixed withfeature/
.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.
Here is the code we use to increment the version number in constants.h:
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