Quote:
|
Originally Posted by ashgrovered
If you make the changes more frequent wont that cause problems with lack of testing in the wild. The code I have done for the mainaux screen required a lot of changes all over the place. Lets say for example that there is an obscure bug in it which is not picked up after a few days, then someone else adds some code and a few week later we get people reporting problems. How will we know where to start looking for the problem
I also think we need to get some volunteers’ to do some testing
|
The idea is that code changes get integrated into the master as soon as possible, then at regular intervals or as and when someone thinks it is due, we can cut a build from the master. People can beta test that and once stable it can go out to release.
The very fact that your change required changes all over the place is reason in itself to integrate those changes quickly. Otherwise you'll find that two people edit the same piece of code making it different to each other. So which one do you use if they both submit changes to the same routines weeks later? Hope you get what I mean.
As far as knowing where to start looking for a problem - the correct way to find it is to debug the software. I don't think it makes much difference whether or not any further changes have been made since a given fault was introduced. This happens all the time in development projects.
Linear Mode
