derrikammons I think there is a key phrase in your reply which highlights the challenge

... if release version is incremented in the master branch, then I wanted the build number to go back to 1.

That is more logic than the Jenkins build number is designed to support. The Jenkins build number is an increasing counter of builds that were launched.

I think you want a release version number with more intelligence than the simple counter that is the Jenkins build number.

There are probably ways to map the simple counter into a release version number, but I think it will be a continual struggle mapping the simple counter to your release version number semantics. I think that the intelligence of the release number will be easier for you to manage elsewhere, rather than trying to derive that intelligence from a simple counter.

Well, markewaite, I suppose you are correct that nothing prevents us from writing the build number ourselves, but I wanted to take advantage of Jenkins auto-incrementing build number feature so that developers don't have to worry about it.  Perhaps I don't quite understand completely the solution you are implying.  I would like for the developers to worry about coding features and fixing bugs, while the build server worries about building and releasing.  I wanted to put the logic in the jenkinsfile pipeline script so that whenever there is a commit the build kicks off and the build number is incremented automatically.  This works fine, but if release version is incremented in the master branch, then I wanted the build number to go back to 1.  The problem is that there are previous builds in the pipeline that prevent it to go back to 1.  Since several developers are merging branches, it's possible that they would make a mistake in setting the build number. Keep in mind the master branch was being built in a Multibranch Pipeline project.  Currently my solution was to remove the master branch build from the Multibranch pipeline project and create a single pipeline project to build the master branch.  Of course this is manual and not fully automated.  I have to create a pipeline project for each release, for example, 5.0.1 (3), 5.0.2 (6), and now we are at 5.3.2 (3) for iOS and likewise for Android, 5.2.0.11.  I had to pull out the master branch builds from the Android Multibranch pipeline project too.  The Mulibranch Pipeline project works perfectly for all the feature branch builds and defect branch builds, but not our release candidate builds.  Our feature branch builds never get their build number reset back to 1.  We just close them and delete them after they are merged into master.  I hope this makes sense.

Hi markewaite, I believe that we actually have no barriers to do that. Actually it is probably better since it seems that resetting the Jenkins build number actually means deleting the builds using those numbers previously, thus losing the build history.

We will implement some kind of auto increasing and resettable build number as part of the build process.

Thanks

What are the barriers that prevent you from encoding the release number in your source files and incrementing that build number when you release software? The Jenkins BUILD_ID really isn't connected to your release numbering technique, while your source code is strongly connected to your release numbering technique.

Ant based builds can have the build.number file. Maven based builds encode the release in the pom file. I believe other build systems likewise have a way of giving the build software (ant, maven, cmake, make, ...) control of the release numbering scheme.

Hi derrikammons,

In my opinion this is not a duplicated of JENKINS-33046

I have a very similar request as you do. In my case the main issue is with Android release in Google Play. Our current version is 2.2.21 and build number is 331, the versionCode becomes 202213312 (20221 is the version, 331 is the build number, 2 is the architecture) but the maximum value allowed in Google Play is 2100000000, which means that we are either limited to 3 digits build number if we reach version 10.x.x or to 4 digits if we assume we will stick to single digit major version.

Thus, as you do, we need to be able to reset the build number back to 1 when the major or minor version increases. Ideally, as you pointed out, this should be done from the JenkinsFile. I am not a Jenkins expert but I don't think that this is possible at the moment.

Since this appears to be a duplicate, I will close this.  I am happy to see that others have ran into the same issue.

It appears that this may be related to https://issues.jenkins-ci.org/browse/JENKINS-33046