CODEWITHSUNDEEP
gitbashawkgit-flowversion-numbering
spdaly
spdaly

Reputation: 1270

Looking for a way automate the "bump version" with git flow

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?

Upvotes: 21

Views: 24388

Answers (9)

Marek Sapota
Marek Sapota

Reputation: 20598

In 2025 bump-my-version is a sill maintained option. semver, bumpversion and bump2version have all been abandoned [^1].

# Install bump-my-version
pipx install bump-my-version
# Or if you prefer
pip install --upgrade bump-my-version

# Generate a config file
bump-my-version sample-config --no-prompt --destination .bumpversion.toml
# Or generate a config file using an interactive questionnaire
bump-my-version sample-config

Edit the config file here as needed, if you're using semantic versioning see here for documentation. If you're using calendar versioning (date based) see here for documentation. All available options are described here. A minimal configuration file is provided below.

Sample minimal configuration defaulting to semantic versioning (.bumpversion.toml file):

[tool.bumpversion]
current_version = "1.2.3"

[[tool.bumpversion.files]]
filename = "my-file-to-update-1.txt"

[[tool.bumpversion.files]]
filename = "src/my-file-to-update-2.txt"

[[tool.bumpversion.files]]
glob = "my-files-to-update/*.txt"

Use these commands to bump your version with the default semantic versioning configuration[^2]:

bump-my-version bump major  # 1.2.3 to 2.0.0
bump-my-version bump minor  # 1.2.3 to 1.3.0
bump-my-version bump patch  # 1.2.3 to 1.2.4
# Automatically git commit the changes and tag the commit
bump-my-version bump minor --commit --tag  # 1.2.3. to 1.3.0, tagged with v1.3.0

[^1]: bump-my-version is a maintained fork of bump2version, which in turn has been (but no longer) a maintained fork of bumpversion. semver gem is unrelated to any of these but it hasn't had any updates in the last 13 years (2025).

[^2]: The tool is very configurable, you can define a different versioning scheme using named regex capture groups along with the parse and serialize configuration options. See the pre-release support configuration for an example.

Upvotes: 0

jackotonye
jackotonye

Reputation: 3853

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

Upvotes: 2

Evandro Coan
Evandro Coan

Reputation: 9466

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.

Obs

I found a solution to hooking the pre-hotfix-commits, it is on the question: How to pre-hook the gitflow hotfix finish?

Upvotes: 0

atripes
atripes

Reputation: 1723

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.

Upvotes: 1

Dave Hillier
Dave Hillier

Reputation: 19073

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.

Upvotes: 3

peritus
peritus

Reputation: 3840

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.

Upvotes: 11

Peter van der Does
Peter van der Does

Reputation: 14498

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

Upvotes: 10

AD7six
AD7six

Reputation: 66299

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.

Upvotes: 18

Danny Schoemann
Danny Schoemann

Reputation: 1350

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

Upvotes: 1

Related Questions