>>Hi Craig,
>>
>>When you say "... then merged in to the source for the new release under development." do you mean that 'source control' does this as a part of its job or do you mean that 2 separate versions are MANUALLY amended?
>>
>>I have trouble picturing it being "automatic", especially in a VFP environment.
>
>The way I've seen this work is that there's only one distributable executable at any time. The "branching" occurs only in the sense that the users which aren't affected with the bug (and fix) are not notified immediately that the new executable can be downloaded, but rather at a later time, when a new (sub)version comes out, or when it's time for a new scheduled upgrade.
>
>What Craig may mean is that there's a development of a new version (say v5.0 of the app) while v4.6.2 is still out there, and some users are still running v4.2 or v3.9. These get their regular updates and bug fixes, and each fix is evaluated by its merits - i.e. whether v5 is affected with the bug, and whether the bug can be fixed the same way in it, or is it time to do the whole thing in a different manner.
>
>Mike Yeager, if he's listening, may tell a more detailed story of how this works - and as far as I remember, it works fine. But then, Siriusware is not a two-man shop.

Using your example above I assume there would be 4 versions of source code in all. Now the big question: are each of these maintained (i.e. fix code manually added to each) separately?

cheers