How to do version numbers?

Question

My company is building a product. It's going to be versioned by SVN. It's a webapp so basically there will never be a version out which doesn't have some features in them and thus could always be labeled as beta. But since it's going to be a corporate product I really don't want the "unstable watchout" on there. So how would you go about versioning? Is 1.0 stable? Should the build date be in the version number? Tell me what you guys think!

Answer 1

If it's in SVN then why not use the SVN revision number?

If you look at the bottom right of this web page you'll see the Stack Overflow version number which is the SVN revision number.

Answer 2

It's pretty popular these days to just use the Subversion revision number.

Answer 3

Or to use your 'thought' version number comma subversion number.. z.B.:

1.0.101 // revision 101, release

or 1.0.101-090303 // with release date, i use this

Answer 4

x.y.z.g

increments in g are unstable.
increments in z are stable and mean bug fixes.
increments in y are stable and mean new features.
increments in x are stable, major release without 100% backward compatibility.

Answer 5

Get yourself some inspiration from Wikipedia: "Software versioning"

Answer 6

Versioning is up to you; I'd put 1.0 on the first version I was confident in. You may want to follow it up quickly with other versions, since some software vendors have given 1.0 a bad reputation.

You do want some way of tying the version number to the exact build used, but you probably want it to be nice and simple for your end users. Consider using standard version numbers, and tagging the SVN repository with the version number included.

Answer 7

I once wrote an elaborate "versioning style guide" for a large project of mine. The project failed to materialize, but the style guide is still available online. It's my personal opinion, perhaps it is helpful (or inspirational) to you.

Beware, it's a long text, and goes into component versioning vs. product versioning and stuff like that. It also expresses strong opinions on some versioning schemes popular in the OSS community, but I have them, so I express them. ;-)

I disagree with using the Subversion revision number, for example. You might want to maintain a released version while continuing development in TRUNK, so you'll set up a maintenance branch - and your revision number versioning goes down the drain.

Edit: As a summary, it distinguishes between versioning source files, components, and the overall product. It uses a system of seperate x.y versoning for components and the product, with a nice interdependency between the two that makes tracing which component version belongs to which product version trivial. It also talks about how to handle alpha / beta / release / patch cycles without breaking the system. Actually, it's a modus operandi for the whole development cycle, so you might want to cherry-pick. ;-)

Answer 8

While just going with the Subversion revision number is nice and simple, it does remove information from the version number. Users might consider this a bad thing.

I assume that your webapp will have some kind of deployment procedure, so that not each revision in Subversion is actually published. Since it is impossible from the "outside" (from the user's perspective) to determine when releases are being made, and how many revisions the code will undergo between them, it makes the numbers almost random. They will be increasing, and I guess it's possible to surmise some kind of distance from comparing two revisions, but not much.

Classical version numbers tend to "dramatize" releases, so that users can build some kind of expectation. It is easier to think "I have version 1.0, now version 1.1 is out adding this and that, that sounds interesting" than to think "yesterday we ran SO revision 2587, today it's 3233, it must be lots better!".

Of course, this dramatization can be inflated too, with companies picking version numbers that are meant to sound more interesting than is motivated by the actual differences in the product, I guess going with the revision number counters this a bit.

Answer 9

I have very little experience in the area. However, here's what I'd do:

1. Choose a scheme for numbering revisions and stick to it. Be consistent.
2. Each version change should represent a significant change. How small a change is significant and the levels of change that are reflected in the version number are up to you.

Of course, you can just use the svn revision number --- like many others have suggested!!!

I hope this helps.

Answer 10

[major].[minor].[release].[build]

major: Really a marketing decision. Are you ready to call the version 1.0? Does the company consider this a major version for which customers might have to pay more, or is it an update of the current major version which may be free? Less of an R&D decision and more a product decision.

minor: Starts from 0 whenever major is incremented. +1 for every version that goes public.

release: Every time you hit a development milestone and release the product, even internally (e.g. to QA), increment this. This is especially important for communication between teams in the organization. Needless to say, never release the same 'release' twice (even internally). Reset to 0 upon minor++ or major++.

build: Can be a SVN revision, I find that works best.

Answer 11

"Version numbers" are a matter for your internal version control system. Release numbers are a different matter (and should be KEPT different).

Stick to a simple MAJOR.MINOR release system (like v1.27), where MAJOR is the compatibility level (version 2.x is incompatible with or at least majorly different from version 1.x) and MINOR is your bugfix releases or minor enhancements. As long as you follow the X.Y format, you can also use other systems like YEAR.MONTH (2009.12) or YEAR.RELEASE (2009.3). But really you're probably best sticking to MAJOR.MINOR unless you have a good reason not to.

Definitely don't use anything that doesn't fit the X.Y format, as it'll make it tough for distros, announcement websites, etc. to work with you, and that alone could seriously affect your project's popularity.

Use branches and tags in your (preferably distributed) version control system to mark specific internal version numbers as relating to MAJORS and MINORS respectively.

And yes, 1.0 should be stable. All releases should be stable, unless they're marked alpha, beta, or RC. Use Alphas for known-broken-and-incomplete. Betas for known-broken. RCs for "try it; you'll probably spot things we missed". Anything without one of these should (ideally, of course) be tested, known good, have an up to date manual, etc.

Answer 12

I would question why you even need a public facing version number. Plenty of successful commercial web apps do without.

Answer 13

We've spent way too much time deciding when to increment the major version. Some shops would rarely do it so you would have releases like 1.25.3 and others would do it for ever release giving you 15.0

I got fed up with that and convinced everyone the major release number is just the year and the minor is just a sequential release within the year. The users seemed to like it and it's a no-brainer to come-up with the next version number.

Year.Release.build

• year = current year
• release = sequence # of public releases with new functionality - reset to 1 every year
• build = incremented for bug fixes and internal releases

EDIT

** Now this was for an internal app that was continually enhanced **

This would probably not work for commercial apps where it's important to have major releases at different times of the year for marketing and financial purposes.

Answer 14

The reason why this question exists is because we don't have a single agreed upon way to do configuration management.

The way I like to do version number is just increment integer from 1. I don't want a multi part version number that I will have to explain or document. And I don't want to use SVN rev number as that will require some explaining as well.

You would need some release scripts on top of SVN to make this happen

Answer 15

We use a simple major.minor.julian_date syntax.

Where;

• major - First release is 1 and then when we introduce major new features or changes so significant they are not backwards compatible increase this number.
• minor - The major milestone releases. For each build pushed by production this number increases.
• julian_date - The Julian Day the build was pushed to QA.

Example of the first release pushed to QA on 1/15 is -> 1.0.015
Example of the first release pushed to Production on 3/4 is -> 1.1.063

It's not perfect, but handy as we push builds to QA near daily.

Answer 16

Some good info here:

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 17

See Semantic Versioning