Software Version Numbers

A.B.C.D

A) Major version number
B) Minor version number
C) Patch number
D) Sub patch number (internal really, nothing to see here)

Sometimes I wish I could video our work discussions to explain to the rest of the world how developers think.  Today we had another talk amongst our developers in the long, long, long never ending quest for the perfect method of defining the version of a piece of software.

The way these things work is we stand in a circle and throw ideas and what-ifs back and forth in order to come to a conclusion on which number deserves to be incremented in the version. This sound like a very minor detail, but it can have major consequences.

General questions defining how to increment the numbers.

• What is a major/minor change?
• Define "sub patch".
• What numbers will customers care about?
• What should we be able to tell by looking at the version number only?
  

Every time you have a patch or a major upgrade headed out the door you go through the following list. They are in random order and have no priority over one another. They must all be gone through. I'm sure I'm missing half of the bullets.

• In which branch of the software development tracking database is the code going to reside?
• What does it fix?
• Does that look like a fix to the customer?
  
• What is the change compatible/incomputable with?
• What will it break?
• What behaviors will the customer have to change?
  
• What will customers have to do to adjust things?
• What will this cause us to have to adjust in the future?
• What industry standards are we hitting?
• Just because it is better doesn't mean people want it.
  
• What needs to be tested?
• What needs to be documented?
• What do we say in the release notes to sell this change?
  
• Will it piss marketing off (a valid concern)?
  
• Existing customers
• New customers
• Competition comparison
• Nag, nag, nag!!
  

"It is just a spelling change!" or "It isn't the same piece of software any more." It doesn't matter really.

It seems like we have this conversation every time we need to make a release. One of the developers said he will add ten more minutes to the seven days he of work hours he has spent on this topic over the last couple years. I'm right there with him.

I made an analogy that is apt for every one of these conversations. We all stand around and throw things back and forth until we feel like we are done and walk away. It is like a band of jugglers who all work in tandem to keep the pins in the air. The conversation is not done until we are all in sync.

Deadlines are a whole new matter.

Even on a patch release x.x.X.x, developers have it in their head that Tuesday at 15:00 is when they can check in the 3600 lines they have changed. They do not take in to account the four hours of documentation and building just for the release. That makes it Tuesday at 19:00 when the package hits the Site for download. That is really Wednesday at 08:00 for customers. Oh, wait, there are four days of testing that need to take place and we forgot to change a bunch of stuff in the user manual. That makes it Monday at 08:00. Meanwhile, the developers are working on the next minor release x.X.x.x.

"We already had the meeting for the next minor release x.X.x.x. That means all those changes will make it in to this version right? "

"NO! dammit! Remember those four days of testing and user manual changes?"

"Oh, we need to add one little spelling change to an error message." This is a valid thing to do, but you have to consider that it will cause all package to be rebuilt and even though they come from the same code base, they are now no longer the binary packages you tested for four or more days. You might have to do some testing over again. Is the change worth that many labor hours?

I'm skipping over the word "merge" on purpose because it causes me pain.