Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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? 1.1.0.0 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 1.1.0.0 and his 2.0.0.0 instead of 1.0.0.xxxy and 1.0.0.xxxz, respectively.

share|improve this question

marked as duplicate by Jim G., Mark Trapp, gnat, Dynamic, ChrisF Sep 26 '12 at 12:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
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 Sep 26 '12 at 4:53
3  
Does nobody understand dave4351's question?... really?.. –  David Cowden Sep 26 '12 at 5:15
1  
@DavidCowden I understand, the question is simple and not constructive - "asking for a poll". I've seen projects going quite well, changing numbers before and after release. –  gnat Sep 26 '12 at 6:41
4  
This question is not a duplicate and should not have been closed! dave4351 is not asking about the semantics of version numbers, like the "possible duplicate", he's asking about when (chronologically) do you edit files to set the number. Totally different question! –  M. Dudley Sep 26 '12 at 13:38
    
I contend that if it was a simple question, more than four people would have understood it. And clearly not a poll as @emddudley pointed out the reasons behind his correct answer. –  dave4351 Sep 26 '12 at 21:48

6 Answers 6

up vote 3 down vote accepted

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

Why?

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 1.1.0.23" 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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 "1.3.0.0" "1.3.0.1".


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

share|improve this answer
    
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 Sep 26 '12 at 21:53

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 1.0.0.0 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.

share|improve this answer
    
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 1.0.0.2592 or 1.1.0.0? –  dave4351 Sep 26 '12 at 1:02
    
Perhaps another way to ask would be: does your 1.0.0 release have a build number of 1.0.0.0 (change at end of cycle) or 1.0.0.2591 (change at beginning of cycle)? –  dave4351 Sep 26 '12 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. –  M. Dudley Sep 26 '12 at 12:27

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.
share|improve this answer
    
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? –  M. Dudley Sep 26 '12 at 12:34
    
As you may see only D is a candidate to be changed automatically on each build. –  Yusubov Sep 26 '12 at 13:18

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