-3

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

  1. 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?

marc_s
  • 675,133
  • 158
  • 1,253
  • 1,388
Agent_Spock
  • 947
  • 2
  • 12
  • 36
  • 1
    You are vastly overestimating how often the database structure changes. Even if it did change with every single update, why would a large upgrade utility be a problem? – JJJ Jun 18 '17 at 08:25
  • @JJJ, if we take my current situation for example my software version is 1.0.2.27 and the update class has 1500 lines lines of code already. – Agent_Spock Jun 18 '17 at 08:26
  • Again, why is that a problem? – JJJ Jun 18 '17 at 08:27
  • @JJJ, the problem is by reaching 3.5.9.2566 version this would actually be bigger than my software. – Agent_Spock Jun 18 '17 at 08:29
  • 2
    And why is that a problem? Although I really can't believe that DB migration scripts could get that big, or you're doing something really wrong. – JJJ Jun 18 '17 at 08:32
  • according to me to update the software from 1.0.0.0 to 1.0.0.1 would suppose make a script of 1MB and now i have to maintain all the scripts upto 3.5.9.2566 then that will be so many scripts dont you think? – Agent_Spock Jun 18 '17 at 08:34
  • 1
    Why would an upgrade script for a minor update be 1MB in size? It just doesn't make any sense. Unless and even if the database structure changes completely, it should be only a couple of lines of code. – JJJ Jun 18 '17 at 08:36
  • My update query consists of updating all the storeprocedures (72 to be precise) and some views in database every time i update it and actually is 700KB of size. So, instead of doing so i just should create a query of those procedure's that need to be really updated? – Agent_Spock Jun 18 '17 at 08:46
  • 3
    Uh... *yes*, the upgrade script should only change the parts that need to be changed and nothing else, not rebuild the entire DB from scratch. – JJJ Jun 18 '17 at 08:50
  • And only check in source code. That's a very important point. – Michaël Roy Jun 18 '17 at 08:52

2 Answers2

0

You should look into Semantic Versioning:

Consider a version format of X.Y.Z (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.

str
  • 33,096
  • 11
  • 88
  • 115
  • Please check the updated question, i forgot to mention that the upgrade log means the changes made by the developer like adding and removing fields in the database which is written in the software. – Agent_Spock Jun 18 '17 at 08:22
  • In this case your question has nothing to do with versioning. Instead you should provide DB migration scripts that run either manually or automatically. These scripts should do all the accumulative changes required to run the application in certain version. – str Jun 18 '17 at 08:26
  • are you saying that i should maintain every separate script for every version update? because if i reach till 3.5.9.1555 version i would have GB's of script to give my customer to update too. – Agent_Spock Jun 18 '17 at 08:28
  • 1
    I am suggesting to have a separete DB migration script required to upgrade from version A to B, from B to C, etc. But if you have GigaBytes of DB migrations then you either did misunderstood something or you are doing it wrong. – str Jun 18 '17 at 08:32
  • no that is what i am saying like according to me to update the software from 1.0.0.0 to 1.0.0.1 would suppose make a script of 1MB and now i have to maintain all the scripts upto 3.5.9.2566 then that will be so many scripts dont you think? – Agent_Spock Jun 18 '17 at 08:35
0

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.

Michaël Roy
  • 5,382
  • 1
  • 12
  • 17
  • i have updated my qustion, i forgot to mention that my platform is VS2008 and tha is why i cant use GitHub etc and actually how does it work? – Agent_Spock Jun 18 '17 at 08:20
  • 1
    @Agent_Spock Why should you *not* be able to use GitHub when you use VS2008? – str Jun 18 '17 at 08:21
  • Can you guide me how to do it? or any kind of article on it? – Agent_Spock Jun 18 '17 at 08:23
  • and sorry for the misleading use of "upgrade log". I mean the queries written by the developer to update the database like updating storeprocedures, views, adding and removal of fields etc. – Agent_Spock Jun 18 '17 at 08:25
  • I am stuck with/use vs as well, and use svn with great success. I even use dos-style .bat files and not a bash for Windows extension. I work remotely, the build machine is actually in a different country. Making the build system took less than 2 weeks, and making a new build is as simple as: branching a to tag on svn. click on build.bat. Change a dependencies file with the new tag for the module, run build for the dependent module, which updates paths for dependencies in the .vcproj fiile. make a tag, build. – Michaël Roy Jun 18 '17 at 08:32
  • The only thing that is not fully automated is changing version # in .rc files and in the installshield projects. PM me if you need more details, or set up a teamviewer/skype session to have a quick tour and see what it looks like. I do not have readme files in the installed projects, but getting logs can definitely be automated. – Michaël Roy Jun 18 '17 at 08:32
  • @agentspock I'm here if you want a quick tour/get details https://chat.stackoverflow.com/rooms/10/loungec – Michaël Roy Jun 18 '17 at 08:47