How to define the version number of a software?

Question

What is the best method to determine the version number I should use for a software or component? Is there a general rule to set version numbers?

I'm pretty sure it is a basic question but I didn't find anything useful after searching a while.

Answer 1

Microsoft have a convention of:

[major].[minor].[revision].[build]

Or follow Jeff's versioning system.

Answer 2

Usually the first number are major changes/major releases, the second number are used when minor features and bug fixes are added, and the third number is used for minor bug fixes and revision numbers.

Ex. 1.0.0

Answer 3

This is a very common question. Are you sure you searched around? Wikipedia has a good article on software versioning.

Answer 4

Depends on a lot of things.

If you are doing .Net work, you can have the system keep track of version numbers for your .dlls and .exe files automatically.

We frequently use the subversion revision as part of our version number. We use a system like:

major.minor.svn-version

We increment the major/minor manually based on internal decisions, and have the svn-version propagate to distinguish builds.

The most important thing is that version numbers make sense to your users.

Answer 5

Do it like Donald Knuth does with TeX---its version converges to π with each release and will in fact become π when he dies.

Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.1415926; it was last updated in March 2008.

from Wikipedia

Answer 6

Or, you can follow Ubuntu's convention of using year and month.

For example, release on April 2009 would be:

v9.04

Answer 7

A common scheme seems to be to use [major].[minor].[revision]. Where the major version number increments on large/major feature changes or rewrites (or stays 0 as long as you didn't reach a stable version, although many open source projects never get past 0 here), minor version number increases on minor changes, such as a collection of bugfixes, an added small feature and the like. revision increments with each build and reflects the smallest granularity of tracking your exact version. Things like small fixes, etc. get rolled into this, usually.

Answer 8

I've been doing this as an interim until I find a better solution. I don't build many large applications, mostly reports and smaller macros, but it's still important for me to keep track of changes and versions.

[Current year].[Current month].[Current day]

FileName 9.7.17.rpt for example.

It works for me and my boss, and it gives a value which you can compare to today's date to see how old the file is. I also keep a changelog.txt file in the same folder as the most current version and it keeps track of all the changes from the previous versions. I also keep track of all versions in a version control page on each projects tab in OneNote.

Thanks for the answer. I'll also throw in how I store the projects for giggles.

Every project gets its own folder. Inside that folder I'll have 4 main items that help me keep track of what's going on in the project.

• An old versions folder
• A folder for any reference material I might need for the project
• The actual project file
• And the changelog

That tree will look something like this.

Project X
    Old versions
        X Report 9.4.12.rpt
        X Report 9.5.3.rpt
        X Report 9.7.20.rpt
    Reference
        SQL calls.txt
        Client list.txt
        Procedures.doc
    X Report 9.7.29.rpt
    X Report changelog.txt

This way of keeping track of my work really cuts down on the amount of time that I need to spend documenting anything and organizes it in a standard way so if my boss needs to grab something I've worked on, even he knows exactly what everything means and where it is.

For storing multiple projects in my network folder I have these folders.

• Inbox
• Projects
  • @Archived Projects
  • Current Project 1
  • Current Project 2
  • Current Project 3
• Reference

Inbox is where I toss random things to process later, or a folder where my boss can throw something I'm going to need for a later project. The Projects folder contains all the projects I'm currently working on, and then when I'm done or they no longer become a current priority, they get tossed in @Archived Projects. Reference is a folder for general job reference material, like policies and procedures, phone lists, org charts, fire escape plans. I may never use them, but it's comforting to have a place to put that kind of stuff as opposed to digging through old email.