Program Versioning - Question for all

[Phenglai]

Howdy everyone,

I wanted to try and get a little discussion going here about you versioning of software and keeping track of it. About 35% of the software I write stays in house but the rest goes outside the company for sale.

I version my software like so: 1.2.5

My questions are:

1. When you upgrade your software, how often do you change the version number?

2. When you upgrade, do you keep all the existing code and copy it to a new folder to keep track of all the versions of the code?

3. How do you document the revisions, in the program or externally in a document?

4. Do you ship the revisions with the software or keep them for your own records?

I am basically trying to find out how everyone else does this to see how close I am to everyone else and to see if there is some sort of standard. I incremement the version with every patch and document the fix in an external text file. I dont copy my code with each revision but have recentl needed to look at some older code but have since upgrade the code to a new version and have been thinking about starting to copy my code with each revision. I know that would get kinda hairy, but with HD's today, space is really not that big of a deal.

Anyway, there it is, just curious to how you guys version your stuff. I know its not a direct VB questions but I searched the forums and could not find anything close to this topic so I will try and start it here.

Thanks,

Jerel

[Lightning]

1 Every upgrade is a new version, a bug-fix changes from 1.2.4 to 1.2.5, a small change from 1.2.5 to 1.3.0 and major changes from 1.3.1 to 2.0.0

2 Use SourceSafe, it is the best way of doing this kind of archiving

3 I prefer an external document

4?

[john24]

1. what Lightning said

2. definitely use source safe of something like it

3. we do 3 kinds of documenting
1) in the code to allow other developers what's been changed and where
2) in source safe in the comments section
3) in an external doc that goes out to customers so they know what's been changed

4. if you're asking about source code, it strictly stays in-house, we ship new dll's for minor fixes and full installs for major fixes/modifications

[Phenglai]

I have never used safe source but will look into getting it up and going.

I do comment, a ton in the code and then externally in a file we keep, then in the program manual for the customer.

So I am pretty much in line with everyone else, just doing it a tad bit different. Will look into safe source.

Thanks alot guys

Jerel

[VBtheone]

hello guys

I have a critical question on versioning the project

I agree that any modification done to the project takes a new version

1- a bug-fix changes from 1.2.4 to 1.2.5

2- a small change from 1.2.5 to 1.3.0

3- major changes from 1.3.1 to 2.0.0

How can I define the minor change ?

and how can I define the major change ?

is there any rules to consider these changes is major or minor or

just a revision?

and what is the limit between them all !

Regards

[MartinLiss]

I annotate code changes in the program. Here is my methodology. I use an add-in to help me insert the *****, etc lines.

When I make changes to an app I always annotate them so that I (or someone else) will be able to understand the history of the changes and will, if necessary, be able to easily back them out. I also record some sort of comment concerning the change in modChangeLog.

Adding Code

If gbNew Then
nSubs = Val(frmMain.txtNbrSubscribers)
'***** CR A27136 Start *******
One or more lines of new code
'***** CR A27136 End *********
Else
nSubs = Val(frmDetMACW.txtUMNbrSubs)
End If
Deleting Code

'***** CR A27136 Start *******
'Load frmDetails
'***** CR A27136 End *********

Changing Code
'***** CR A27136 Start *******
'nDummy = WritePrivateProfileString("Defaults", _
"IntegrationType1", sInteg, gsIniName)
'gsDefIntegType1 = sInteg
Select Case True
Case gbNova
nDummy = WritePrivateProfileString("Defaults", _
"IntegrationType1", sInteg, gsIniName)
gsDefIntegType1 = sInteg
Case gbWorld
nDummy = WritePrivateProfileString("Defaults", _
"IntegrationType3", sInteg, gsIniName)
gsDefIntegType3 = sInteg
End Select
'***** CR A27136 End *********

Overlapping Code

When annotations overlap, the new annotations are placed inside the older one(s).

'******* CR A27136 Start *******
'***** 05.00.001 Misc #99 Start *******
'gbNova = True
gbWorld = True
'***** 05.00.001 Misc #99 End *********
'******* CR A27136 End *********
What the above shows is that CR A27136 initially added the gbNova = True line and the Misc #99 change, which occurred later, changed that line to gbWorld = True.

[RudyL]

Just to stick my 2 cents in..

When I make a change if it is minor I change the minor value, if it is major I change the major value.. The revision number, or build number will be changed by how many times I compile the code for that release..

example,

Code currently at 1.5.7

Needs a minor change, code goes t 1.6.2 (Took 2 builds before I was ready to release)

Needs a major change, code goes to 2.0.2(again, took 2 builds before I was ready to release)

I really comes down to a judgement call about minor vrs major version numbers.. You have to decide if the change you made was "big" enought to warrent a major number change..


Just me 2 cents..

:)