软件版本控制

Question

Platform : Visual Studio 2008 (I know it's old but I have my own reasons).

I am new to the concept of software versioning so I need advice as how to use it.

Currently, here is how I use software versioning:-

• 1.0.0.0 to 1.0.0.1 (For bugs removal)
• 1.0.0.0 to 1.0.1.0 (For minor changes in software like performance improvement)
• 1.0.0.0 to 1.1.0.0 (For addition of certain functionality in software)
• 1.0.0.0 to 2.0.0.0 (For major updates)

I learned this from here .

Now the problem I can think of is that when the software reaches version 3.5.17.3485 from version 1.0.0.0 then there would be bajillion lines of code. For example:

Update 1.0.0.0 to 1.0.0.1

1. Used stored procedure instead of a view
2. Backup feature added

Update 1.0.0.1 to 1.0.0.2

1. Improved backup feature utility.

Update 1.0.0.2 to 1.0.0.3

2. Bug fixed in software backup feature.

Now lets assume that updating from version 1.0.0.0 to 1.0.0.1 took 40 lines of code to change the design of database or files stored in the system and for every separate update it will take more and more code depending upon the update. Now after reaching 3.5.17.3485 version think of how many lines of code will be there.

Can anyone tell me how to handle such a situation?

Answer 1

You should look into Semantic Versioning :

Consider a version format of XYZ (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

Only releases that change the major version actually might require the user of your application to change his/her own code.

Answer 2

Why would the developer need to maintain update logs? If you use svn/git or anything else the task can easily be automated. Also, I think everyone would be quite happy if the readme/history files for version 3.5.17.xxx were only containing logs since version 3.5.0.0.

Automating as much as possible of the build system has many advantages, not the least being that an automated task cannot forget things when doing a 'quick' fix, or a special release for a client.