Possible Duplicate:
What “version naming convention” do you use?

Do you change your major/minor/patch version numbers right before you release or right after?

Example: You just released 1.0.0 to the world (huzzah!). But wait, don't celebrate too much. 1.1.0 is coming out in six weeks! So you fix a bug and do a new build. What's that build called? or 1.0.0.xxxy (where xxxy is the build number of 1.0.0 incremented)?

Keep in mind you may have 100 features and bugs to go into 1.1.0. So it might be good to call it 1.0.0.xxxy, because you're nowhere close to 1.1.0. But on the other hand, another dev may be working on 2.0.0, in which case your build might be better named and his instead of 1.0.0.xxxy and 1.0.0.xxxz, respectively.

  • 3
    I'm not asking if you use major.minor.release.build or some other scheme. I'm asking at what point in the release cycle do you change the number to 3.2.0? When you first start coding 3.2.0 or when you release 3.2.0?
    – dave4351
    Commented Sep 26, 2012 at 4:53
  • I reopened the question as it is not a "how" question but instead a "when" question. It is still very similar to the previous marked duplicate however and may be closed again.
    – maple_shaft
    Commented Oct 13, 2014 at 23:15
  • You can be inspired - commons.apache.org/releases/versioning.html
    – jnemecz
    Commented Jun 18, 2017 at 21:48
  • My question is: who owns the version number? And, this question doesn't differentiate between built binary version, the file version itself, the package version containing the next version of the library. But who owns the decision to change the major/minor version number? Depending on the versioning hierarchy being used, perhaps the devs can own the major/minor version increments for the binaries/files, but in terms of packages containing the built binaries, that's the release management team/project owner or some other responsible party? Commented Oct 24, 2023 at 18:54

7 Answers 7


After you release your software, the version number should be incremented immediately.


Let's assume you're following a scheme like Semantic Versioning, and you have a build number in the version. So you might have [Major].[Minor].[Patch].[Build]. I am going to call the [Major].[Minor].[Patch] part the version.

You will be creating multiple builds during development. Each build is a development snapshot of your next release. It makes sense to use the same version for your development and release builds. The version indicates what release you're working toward.

If you're preparing for release and the software passes all of its tests, you won't want to rebuild and retest the software just because you had to update the version. When you eventually make a release, you are stating that "build" shall henceforth be referred to as "version 1.1.0".

The increment-after-release model makes sense for branching too. Suppose you have a mainline development branch, and you create maintenance branches for releases. The moment you create your release branch, your development branch is no longer linked to that release's version number. The development branch contains code that is part of the next release, so the version should reflect that.

  • 1
    Yes, but to what version? A patch version only, e.g. you released 1.0.0, so the "next" version is 1.0.1? Why not 1.1.0? You don't know ahead of time what version you'll be releasing until it's actually released--but now I'm delving into version hierarchies. There's the binary version (e.g. assembly/JAR), the file version (the actual file containing the assembly/JAR), then there's the release package version. The release package version is the one consumers will deal with, and releasing is (usually) a business decision. Commented Oct 24, 2023 at 18:59

I generally try to use SemVer for internal version numbers. It's nice to be able to know something about a release based on the semantics of its version number.

During development, I try to change version numbers straight away (if possible). Sometimes it is hard to know whether the change will be a breaking change or not (which will influence my version number), so nothing is "set in stone".

To address your specific example:

  • During development, pre-release versions would be 1.0.1-alpha.1, 1.0.1-alpha.2, etc.
  • The final release of the bug-fix would be version 1.0.1.

Having said that, the 'public-facing' product version numbers are often set by marketing, and are completely different. This is out of my control, so no point worrying about it.

  • A better question is, who is responsible for owning the decision on what the next release version will be? I believe devs could probably own binary/file versioning, bu t anything above that may not be owned by the developers, but by stakeholders within the business, such as a release management team or a product owner. Commented Oct 24, 2023 at 19:00

Let's assume A.B.C.D in the answers. When do you increase each of the components?

It is basically determined by your company policy. Our company policy is:

  • A - Significant (> 25%) changes or additions in functionality or interface.
  • B - small changes or additions in functionality or interface.
  • C - minor changes that break the interface.
  • D - fixes to a build that do not change the interface.
  • 4
    Yes, but dave4351 is asking about when (chronologically) do you actually edit these values in source control? You don't change the version number every time you check in code, do you? Commented Sep 26, 2012 at 12:34
  • 1
    As you may see only D is a candidate to be changed automatically on each build.
    – Yusubov
    Commented Sep 26, 2012 at 13:18

In larger projects/organizations, the major and minor version numbers are controlled by marketing departments and are usually incremented for marketing reasons. At my organization, groups aim to release one major and one minor release each year. The expectation is that major releases contain significant new functionality and there is binary compatibility between APIs for all releases with the same major version number. However, marketing may choose to downgrade a major version change to minor because promised features are not delivered or vice versa to been seen to leap frog competition, for example.

The major and minor build numbers (c and d in a.b.c.d) are usually controlled by development. c is the build number and d is used for patches on a particular release or version of c.

In your case, when you change the major and minor version numbers is less relevant than ensuring the major and minor build numbers are accurate. At my organization, we change the major and minor build numbers as part of the branching process in source control. The main branch usually contains the latest version but marketing may not have decided what version number the release will have yet.


We try and follow the Eclipse example. It does a better job of explaining than I can, but effectively for us it works like this:

When you release the version number you change to is dependent on the type of change that you are making.

  • A release that does not effect the API, consider a behind the scenes bug fix that makes the current API work in the expected way, is released at 1.0.1
  • A release that adds to the API but does not change the existing API, you may have added a new feature that does not make current clients incomparable with the new version. This can include any number of the above fixes as well.
  • A release breaks the current API, removing something, changing something in the way that breaks the comparability with current clients. This can have any umber of the above fixes as well.

As for how to use the 4th section in the version number we use this to differentiate different builds in Nuget (the package managment solution we use for .net). This allows us to avoid having to clear the caches each time we need to update our unreleased software.

  • I am specifically asking about builds between versions. Following a 1.0.0 GA release, does your very next build, working toward 1.1.0, have a version number that looks like or
    – dave4351
    Commented Sep 26, 2012 at 1:02
  • Perhaps another way to ask would be: does your 1.0.0 release have a build number of (change at end of cycle) or (change at beginning of cycle)?
    – dave4351
    Commented Sep 26, 2012 at 1:03
  • -1 Does not address the question of when to increment the version. The Eclipse document just talks about the semantics of version numbers. Commented Sep 26, 2012 at 12:27

There is no next build. On that branch.

Idealized version of our scheme.

Version identification on any branch is PRETTY_BRANCH_NAME-build and PRETTY_BRANCH_NAME is fixed at branch creation.

Our branching scheme(*) is the following:

Top level branches, the PRETTY_BRANCH_NAME of each is a code name, speaking of version number at that level is meaningless, there may be a planned scheme but it will change before the release.

  • a TNG (the next generation) branch where long term development is made. Often we don't even have it and it has never (release) subbranches.

  • a TCG (the current generation) branch where current development is made. PRETTY_BRANCH_NAME is a code name.

  • a TPG (the previous generation) branch. Often no more development is made here, but there may be activity in the subbranches.

A subbranch is made of a top level branch (of TCG, in presence of slow migration of TPG) when beta for a major release start. The PRETTY_BRANCH_NAME is something like "1.3.X" (X is the letter, not the digit, it means we intend to deliver 1.3 releases from here), feedback from beta is token into account here while work for the next major release is done on the TCG branch.

Ideally, release should be snapshot on that branch, but we know we aren't perfect and often need to do last minute changes while allowing others to continue to work for the next minor release. Thus subsubbranches are made for the final stabilization with pretty names being the official version number (at that time even marketing won't want to change it) like "1.3", "1.3.1" out of the "1.3.X" branch, the last build on each is the release.

If we had a fourth level, the subsubbranches names would have been "1.3.0.X" out of which we'd have had sub^3branches "" "".

(*) At the release level. There may be project subbranches on each of these.

  • Thanks for this. I accepted a different answer that was more in line with my thoughts, but this is good information if you're using branches a bit more.
    – dave4351
    Commented Sep 26, 2012 at 21:53

If you are selling software then you will have a new major release each time sales/marketing needs to earn a bigger bonus :-).

If you have some control then:

  1. Major releases when:

    • There is some incompatibility with the previous release that requires conversion etc. like from Python 2 to Python 3.

    • There is a whole chunk of new functionality.

  2. Minor releases for any small changes in functionality.

  3. Patch release for bug fixes.

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.