How do you know what version number to use?

Question

Here\'s one I have always wondered about...

Please excuse my naivety, but - How do you decide what version number to name your software?

I assume, when someb

Answer 1

To add to all the explanation above, I will suggest use a versioning scheme which, will be easy for your customers to remember and easy for you to baseline and manage your software versions. Also, if you are supporting different framework such as .Net 1.0, .Net1.1 etc, then make sure your versioning scheme takes care of that also.

Answer 2

some good info here as well..

When to Change File/Assembly Versions

When to Change File/Assembly Versions First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.

Non-Shipping Builds In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.

But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.

Shipping Builds As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user’s disk with outdated assemblies.

When You Change Your Assembly Versions To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.

Answer 3

It depends on the project. below is haskell's package versioning policy.

-- The package version.  See the Haskell package versioning policy (PVP) 
-- for standards guiding when and how versions should be incremented.
-- http://www.haskell.org/haskellwiki/Package_versioning_policy
-- PVP summary:      +-+------- breaking API changes
--                   | | +----- non-breaking API additions
--                   | | | +--- code changes with no API change
version:             0.1.0.0

Answer 4

We assign each build of any application unique four part version number defined as Major.Minor.Maintenance.Build.

Major - The Major number is associated with significant changes to the application. This number also determines compatibility with other applications in the same "suite". This number is incremented when new releases are made. This usually means major architectural changes have taken place.

Minor - The Minor number is associated with new functionality and breaking bug fixes. Any time new functionality is introduced or when a breaking bug fix is applied, this number will be advanced and the Maintenance number will be set to zero.

Maintenance - The Maintenance number is associated with non-breaking bug fixes. This number will be advanced whenever a release is made that contains only non-break bug fixes.

Build - The Build number is associated with the subversion changeset (revision number) from which the application was compiled. This will provide an easy way of matching the version number to a precise set of code in subversion.

The only number the developers are really interested in this scheme is the Build. number. By tying the Build number to the subversion revision number we can guarantee what code was used to create the released application.

Answer 5

Whatever numbering scheme you pick, it is critical to make clear to your users when a new version is compatible with old client code versus when a new version requires changes to existing clients. Most projects I know bump the very first number when client code has to change.

Beyond compatibility, I too think there's a lot to be said for using dates. Although it gets embarrassing if, like me, your release schedule is once every two years (but that's for a tool first released in 1989).

Answer 6

In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.

A bug fix release needs to preserve binary, source, and serialization compatibility.

Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.

Major version numbers can break all three forms.

I wrote more about the rationale here.