What is versioning?
The practice of documenting that a change has occurred so that all team members are aware of the most up to date information.
How to version your application:
1.2.14
The 1 above represents a major release of new functionality. Pretend this is your first house that you have built. The .2 above represents a minor release of updated functionality. Pretend that you haven’t accepted your brand new house from the contractors yet and that you have asked them to replace a door within your house, since you didn’t like it, and you asked them to do it twice. The .14 above represents “hot fixes,” “quick fixes,” “patches” of functionality. Pretend that you have asked the contractors 14 times to paint your living room a different color, you just weren’t happy until that 14TH coat of paint color went up. All together 1.2.14 is your house in its current state. Should you want any changes done, the number would increase, the number will never decrease. Same on applications. Sometimes you might have an application that is 10 years old and hasn’t been versioned before, prior to making any changes, that applications version is just 1.0.0. Once you make your updates, then increase the number as appropriate.
The application version number should always appear on the home page of the application at the bottom or in the view page source at the bottom. Anyone at any time should be able to know what version they are working on or with. But we have this fancy tool that auto updates the version? And what if that tool fails or doesn’t complete? Manual versioning on top of automated versioning is a recommended practice.
How to version your documentation:
7.0
I’m not sure what the real reason is for the complexity of actually versioning documentation is, but across the IT world, it really is a hit or miss on if it’s being completed correctly. I’m still unsure if it is laziness or just a lack of training? So here goes, you start with 1.0 and every time the document gets updated, the version number gets updated. Yes, that means if you change the word: “the” to the word “and” that’s a new version. Maybe it’s just better to see it in action:
Revision History
| Version | Date | Name | Section(s) Updated | Notes |
| 1.0 | 05/06/2015 | Heather Derringer | All | Initial |
| 2.0 | 05/08/2015 | Heather Derringer | 2 | Tom and Brad’s updates |
| 3.0 | 05/12/2015 | Heather Derringer | TOC & 2 | Carol’s updates |
| 4.0 | 05/12/2015 | Heather Derringer | 2 | Partner update |
| 5.0 | 05/12/2015 | Heather Derringer | 2 | Partner updates |
| 6.0 | 06/10/2015 | Heather Derringer | 6 | Partner Extended |
| 7.0 | 06/20/2015 | Heather Derringer | 3 | Cost update |
These are the most basic fields of importance, the Version number, the Date of the change, the Name of the person whom completed the change, the sections of the document that were updated, and the Notes column of who requested the update or what the exact update was.
How to version your requirements:
1.2.3
Hopefully we have at some point in our careers seen very good requirements. I’m pretty sure that all of us have seen horrible and bad requirements at one point or another in our careers. And I’m here to tell you to keep it as simple as possible when versioning requirements. 1.1.1.1.1.1.1.a.b.c.23 is not simple, is totally confusing and will confuse anyone that is trying to understand and work off of requirements. And yes, I’ve seen that before, I didn’t just make that up out of thin air. So let’s take a look at some semi-decent requirements here: (trying to focus on the versioning)
| # | Requirement | Additional Information |
| 1.0.0 | Home Page is displayed | |
| 1.0.1 | Home Page is not displayed – server error page | 404 |
| 1.0.2 | Home Page is not displayed – update browser page | Update browser |
| 1.1.0 | Home Page displays company logo in top left hand corner of the page | ![]() |
| 1.2.0 | Home Page displays instructional text to the right of the logo | Brute omnesque his id. Populo interpretaris ad usu, etiam altera mel te. |
| 1.2.1 | Home Page displays survey section under instructional text | Brute omnesque his id. Populo interpretaris ad usu, etiam altera mel te. |
| 1.2.2 | Home Page displays live chat section under survey section | Brute omnesque his id. Populo interpretaris ad usu, etiam altera mel te. |
| 1.2.3 | Home Page displays contact us section under live chat section | Brute omnesque his id. Populo interpretaris ad usu, etiam altera mel te. |
| 2.0.0 | Login function is displayed under the logo on the left hand side of the page | |
| 2.0.1 | Email Address input box is displayed | Errors |
| 2.0.2 | Password input box is displayed | Errors |
Can we easily find our 1.2.3 requirement? Yes. Do we know what the requirement is? Yes. Could we start coding and testing this? We would probably want to know a few more things about the requirements, but we could at least complete mock-ups of the pages that’s for sure.
The reason we want to keep versioning shortened on requirements, is because some tools won’t accept requirements correctly, meaning your requirements would display like this:
1
11
2
There is an easy fix for that, which is to add 0 in front of them if you have less than 99 requirements:
01
02…..
11
And two zero’s if you had 100 or more requirements:
001
002….
011
If you still aren’t convinced of not using 1.1.1.1.1.1.1.a.b.c.23 requirement numbering system, maybe you need to think about breaking your project up into multiple projects.
Why version?
Well let’s go back to our house here. Your contractors all have version 3 of the house plans. Version 3 is 2K square foot house. The managers of those contractors all have version 5 of the house plans. Version 5 is 4K square foot house. As the owner/builder you have version 7 of the house plans. Version 7 is 5K square foot house. If everyone is working off of different versions, which size house do you really expect to be built? What do you think size house you are really going to get? Versioning properly makes the world of difference.
