27

I didn't learn programming at school and I do not work as a (professional) developer, hence a lot of basics are not quite clear to me. This question tries to clarify one of them.

Now let's suppose that I have issues #1, #2 and #3 in my Issues Tracker that are set to be corrected/enhanced for version 1.0.0 and that the last (stable) version is 0.9.0.

When should I increment to version 1.0.0 ? When a) just one of the listed above issues is closed or b) when all the issues related to version 1.0 are closed ?

Which one is the right way to do it ? And by the right way, I mean what is currently used in the industry.

Joachim Sauer
  • 10,956
  • 3
  • 52
  • 45
ahmed
  • 403
  • 1
  • 4
  • 9

5 Answers5

22

Version numbers are only relevant for releases, since they are a way for external users to identify a specific build of your software. If you're just busy doing development and not releasing each fix individually, then don't worry about incrementing the release number for every fix. It's not relevant to external users and wastes your own time with extra version bookkeeping.

Greg Hewgill
  • 10,181
  • 1
  • 46
  • 45
  • Does this apply also to web development where a release can be a simple hotfix to a minor bug ? – ahmed Oct 21 '13 at 21:50
  • 4
    Do you do QA before issuing the hotfix? It's a release. If not of the full product, then of the hotfix. – Peter K. Oct 21 '13 at 21:54
  • @ahmed In such a scenario, the version numbers are often invisible to the user and thus meaningless (release numbers primarily exist for marketing and tech support, both of which do not apply for many webapps). Just using the commit ID might be sufficient. If you insist on using version numbers, yes, I'd probably increment the patchlevel. – amon Oct 21 '13 at 21:55
  • I'm learning a lot of things here :p So, to sum it up : I do NOT need versioning numbers as commit IDs are sufficient, since ALL users will be using the last version anyway. – ahmed Oct 21 '13 at 22:15
  • 2
    Although all users are on the same version, by the time you look into the defect report the version will have moved on. You still need a way to tie the report to a specific build of the software (date/time might be good enough). – mattnz Oct 21 '13 at 22:32
  • One approach for a web app is to embed the revision number (or something related) into the page output itself. You can see an example of this at the bottom of this very page. At the moment I'm writing this, it says "rev 2013.10.21.1077" in small light grey text. I am certain this is automated and nobody manually updates the version number. – Greg Hewgill Oct 21 '13 at 22:35
  • If your builds and versioning are automated there is no extra bookkeeping. IMO it good practice to version all your fixes and enhancements and have that carry through from release to pkg version to repository tag to changelog entry. – dietbuddha Oct 22 '13 at 04:09
  • @dietbuddha: true, but that doesn't mean all your fixes need to have a *different* version number. Rolling up multiple fixes into one version release is obviously common practice. – Greg Hewgill Oct 22 '13 at 04:14
  • For constantly-deployed web applications (the usual single-source-single-installation kind), I'd personally just use the build number to identify each version. For those, semantic versioning is probably overkill. – Joachim Sauer Oct 22 '13 at 08:02
  • Each build should have a specific version number, even internal builds. It greatly reduces misunderstandings as it makes things far more explicit. Within development as well as when communicating with QA and/or other non-development testers. We currently use .... Buildnumber is taken from the change list number of the last change committed to the branch being built. – Marjan Venema Oct 22 '13 at 08:04
19

I can tell you how I do it at work.

We have a continuous integration server that builds, tests, tags and outputs a versioned package. We only proceed to the next stage if the previous one is %100 successful.

Our version looks like this: <Major Version>.<Minor Version>.<Build Number>

  • Every successful build that has no completed bug fix or feature enhancement increments the Build Number.
  • Every successful build with a completed bug fix or feature enhancement increments the Minor Version. This is automatically detected by the presence of a commit message using a particular format. This commit message also automatically get's pulled into the projects ChangeLog.
  • Every Major Version increment is done by hand when we have non backward compatible changes, rewrites from scratch or other reasons made on a case by case basis.
dietbuddha
  • 8,677
  • 24
  • 36
  • But if you have a series of enhancements to be completed on a , 1.0.0 for example. Do you need to do **ALL** these enhancements to be able to say "OK! Now this is the version 1.0.0" or you increment to version 1.0.0 as soon as the first enhancement is done ? – ahmed Oct 22 '13 at 11:32
  • @ahmed I've seen the approach that `1.4.2` is "this set of fixes, and anything else ready at that time"... I've also seen `1.4.2` as "This will be released on this date with whatever is ready". It depends on your release cycle. –  Oct 29 '13 at 18:18
  • 5
    @ahmed If the criteria for going from 0.x.x to 1.x.x was the completion of a set feature/fixes then I would only increment after they were all complete. Note: that we don't work that way at all. We don't target a version and decide what fixes go in it. We target the fixes. The version we get is purely for tracking and identification not a goal. – dietbuddha Nov 02 '13 at 01:24
  • This is exactly what I wanted to know :) – ahmed Nov 02 '13 at 11:44
2

For continuiously deployed web applications, we tend to construct build numbers using symver up front and a build number tailing, ie: 2.5.3.4328 where 4328 comes from the continuious integration system. General expectation is that numbers change by deliberate steps but that the build number is the true unique ID.

What it seems to be doing here is capturing the day of deployment and the related svn build number:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

For what it's worth.

Wyatt Barnett
  • 20,685
  • 50
  • 69
1

The other answers are great already, so I'll only add on top of them. If your software is not released and you don't really need public versioning (the non-public versioning is your VCS), then append the keyword "SNAPSHOT" at the end of your version. Some systems, especially in dependency management, treat snapshots differently from released versions in that they compare the change date of the snapshots instead of the version number. So if you had a v. 1.0.0-SNAPSHOT from 8am in a package repo and a local dependency downloader has the same version from 7am, it shold download the updated one from the repo.

As said above, your private versioning is provided by your version control system (git, svn etc.).

Hubert Grzeskowiak
  • 250
  • 4
  • 9
1

There's enough said about the theory of versioning here's another viewpoint.

When should I increment to version 1.0.0 ?

I'm going to focus my answer on change of the major version number.

My answer is: Basically when you're ready for it. Going from 0.9 to 1.0 is a big thing, because public perception will be that you're going from a beta-product to an official release.

(I'm going to assume here it's a commercial product from a company).

A few questions before going from 0.9 to 1.0.

Does your organization have the time to inform all your current clients. To throw a party. Get a lot of support requests. An account manager to sell your product? Etc. etc.

Yes I see the versioning as a marketing tool and if you look around you see that that basically is the industry standard.

Our company went from version 2.x to 3.0 and had a great party, created a lot of buzz and because of that got quite a few new clients. Apart from some interface updates the differences between the versions were quite minor.

Pieter B
  • 12,867
  • 1
  • 40
  • 65