Hi,
I'm after some ideas / 'industry accepted best practice' for documenting the modification history to an asp.net app I am in the process of moving from classic ASP.
In the past, with classic ASP, each page of a given application has only 1 source file (the .asp file), so its been easy. I would write each .asp file with its own version number and detailed mod history comments; and then have an include file which all pages included which had the master application version number and the 'higher level' mod history for the app as a whole.
But now its different - everything is split out (for the right reasons I might add). So, each page now has 2 files - the .aspx, and the code behind .aspx.vb
Then we have the web.config file (which I current use to store the application version number)
And then we have the classes - and thats where it gets messy in my mind.
Lets say I have application A. It has:
And now consider that I have application B. It is setup in the same way as app A (web.config, aspx, aspx.vb files, and some classes). But some of the classes it uses are the same as app A (after all, thats what OO is all about)
What happens when I need to make a change to one of the classes that both apps use ? Even if its a change to a method that only app A uses ?
Of course I up the mod history of the class, and presumably the overal version number and mod history in web.config for app A (app A being the application that required the change)
But what about app B ? I've not change it, and it still functions exactly as it did before (big assumption there
), so I should not need to up its mod history or version number. But one of its classes has changed - so there has been a change to document .....
Presumably this dillema affects all OO architectures ??? What do other people do ??
I'm after some ideas / 'industry accepted best practice' for documenting the modification history to an asp.net app I am in the process of moving from classic ASP.
In the past, with classic ASP, each page of a given application has only 1 source file (the .asp file), so its been easy. I would write each .asp file with its own version number and detailed mod history comments; and then have an include file which all pages included which had the master application version number and the 'higher level' mod history for the app as a whole.
But now its different - everything is split out (for the right reasons I might add). So, each page now has 2 files - the .aspx, and the code behind .aspx.vb
Then we have the web.config file (which I current use to store the application version number)
And then we have the classes - and thats where it gets messy in my mind.
Lets say I have application A. It has:
- a web config file
I put the application version number, and general app mod history comments in there
- some web pages, 2 files each (.aspx and .aspx.vb)
I put the page version no and detailed mod history in the .aspx.vb files
- some classes
I put the class version no and detailed mod history in each class .vb file
And now consider that I have application B. It is setup in the same way as app A (web.config, aspx, aspx.vb files, and some classes). But some of the classes it uses are the same as app A (after all, thats what OO is all about)
What happens when I need to make a change to one of the classes that both apps use ? Even if its a change to a method that only app A uses ?
Of course I up the mod history of the class, and presumably the overal version number and mod history in web.config for app A (app A being the application that required the change)
But what about app B ? I've not change it, and it still functions exactly as it did before (big assumption there
), so I should not need to up its mod history or version number. But one of its classes has changed - so there has been a change to document .....Presumably this dillema affects all OO architectures ??? What do other people do ??
Comment