This is not a question about how to number versions.

We have an application with a certain version numbering scheme. We also have a Jenkins CI server (soon to be replaced with Atlassian's Bamboo) that regularly builds our software. The application displays the version number, so it's written in one of the files in our code base.

We don't want to manually change the version number before releasing a version. Our current solution is that we have a Jenkins job that changes the version number in our code base, commits it, tags the repository with the version number, pushes it and then packages the application for distribution. The problem with that is that we have to decide to release a version before the build succeeds or fails.

What we want to do is this: have Jenkins regularly build our product and run the unit tests. Afterwards, we want to select a passing build and release it with a certain version number.

In summary, this is the process I want:

  • Jenkins builds and tests our product regularly.
  • When we want to release a version, we can select the last passing build from Jenkins and check to release it.
  • The resulting release should include the version number.
  • The commit that was built and released should be tagged with the release number.

What is the best practice for releasing product versions? Is there a process that will meet my demands?

  • 1
    fork on the commit that you want to release, versionize and tag the result Commented Jul 18, 2014 at 10:18

1 Answer 1


We have a similar situation, and I setup our build/release process like this:

  • Our version numbers consist of four parts (major, minor, build, revision). The first two parts are only changed after a release, the other two change for every build. In our case, the major & minor version come from Jenkins build parameters, the revision number comes from subversion and the build version is the build number of the Jenkins job that performs the build. You could also read the major & minor version number from a file in the repository.
  • Jenkins writes a file that the software uses to determine its version number.
  • This file is archived within Jenkins as a build artifact, but it is not committed to the repository. This way, each build has a unique version number that can be retrieved later, but the version numbers are not tracked in the repository.

  • For making a release, we have a Release Jenkins job. This job doesn't actually build anything, but it takes as parameter which build we want to release and tags the repository at the revision for that build and marks the build in Jenkins as a release (using the build promotions feature). The file with version information can be used to determine the version number that should be encoded in the tag name.

  • This is the proper way to do things. Have multiple jobs.
    – Ramhound
    Commented Jul 18, 2014 at 12:55
  • There are two sentences here that seem to contradict: "You could also read the major & minor version number from a file in the repository." and "This file is archived within Jenkins as a build artifact, but it is not committed to the repository.". What am I missing? Commented Jul 18, 2014 at 13:57
  • The parts of the version number that only change after a release could be stored in the repository. They need to be updated manually anyway after making a release. The file that isn't stored (or updated) in the repository contains the full version information, including the parts that change every build. Commented Jul 18, 2014 at 18:21
  • Right now my "release version" build in Jenkins changes that file in the repository and commits it. Isn't that better than doing it manually? Commented Jul 18, 2014 at 21:03
  • @AmirRachum: That might indeed be better. For me it doesn't make a difference, as I use build parameters. Commented Jul 19, 2014 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.