28

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.

Improve this question
4
  • 25
    See semver.org
    – Martijn Pieters
    Commented Oct 21, 2013 at 21:27
  • 1
    And you can include all three issues in your next release too.
    – Martijn Pieters
    Commented Oct 21, 2013 at 21:27
  • Yes, I'm already using SemVer and ALL three issues are due in the next release :)
    – ahmed
    Commented Oct 21, 2013 at 21:34
  • I edited the question to avoid confusing.
    – ahmed
    Commented Oct 21, 2013 at 21:55

5 Answers 5

Reset to default
20

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.
Improve this answer
4
  • But if you have a series of enhancements to be completed on a <Minor Version>, 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
    Commented Oct 22, 2013 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.
    – user40980
    Commented Oct 29, 2013 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.
    – snakehiss
    Commented Nov 2, 2013 at 1:24
  • This is exactly what I wanted to know :)
    – ahmed
    Commented Nov 2, 2013 at 11:44
25

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.

Improve this answer
10
  • Does this apply also to web development where a release can be a simple hotfix to a minor bug ?
    – ahmed
    Commented Oct 21, 2013 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.
    Commented Oct 21, 2013 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
    Commented Oct 21, 2013 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
    Commented Oct 21, 2013 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
    Commented Oct 21, 2013 at 22:32
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.

Improve this answer
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.).

Improve this answer
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.

Improve this answer

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.