The Dilemma With Multiple Versions of Source Code

We’ve been trying to tackle the topic of how to support multiple versions of software safely.  The emphasis has been on ensuring the changes you make to software are the only changes reflected in a build.  This is different than your changes being included with other changes done you’re not aware of.  Shared libraries are the most obvious examples I can think of.  Getting in to that situation introduces loads of risk we have no interest in taking on.  Alas, that is the situation we’re in today.

Scenario: Library changes and we need to update an older version

In this scenario consider we have a shared library with a bunch of classes in it.  That shared library is included in a web app we released.  We label the solution as “My App 1.0.0”.  Over time the shared library is modified to the point the it loses backwards compatibility for one reason or another.  The modified solution is known as “My App 2.0.0”.  Suddenly we come across a bug with the “My App 1.0.0” version which requires emergency resolution in the shared library.

We can’t get latest on that library to apply our fix because latest is now “My App 2.0.0”.  If we get from the label “My App 1.0.0” we could make our fix and mark it as “My App 1.0.1”.  The problem then is checking that code back in would become “latest” where in reality “My App 2.0.0” should continue to be the latest.  Of course, we’d want to apply our fix to “My App 2.0.0” if it still applies.  

A proposed solution:

1. Get “My App 1.0.0”
2. Apply fix
3. Check in the code and label solution as “My App 1.0.1”
4. Get “My App 2.0.0”
5. Apply fix
6. Check in the code and label solution as “My App 2.0.0”

Another proposed solution:

1. On release, branch "My App 1.0.0" to a Release area of your repository.  The branch would include all libraries necessary to support the application.
2. Continue developing "My App 2.0.0" in the trunk
3. To fix something in "My App 1.0.0" update the branch created earlier and apply a label such as "My App 1.0.1"
4. Merge changes from "My App 1.0.1" in to the trunk where "My App 2.0.0" is being developed

Both options provide a fix to “My App 1.0.0” to be tested and released, applies the fix to “My App 2.0.0”, and leaves “My App 2.0.0” as “latest”.  If in the future another fix were needed for “My App 1.0.1”, we’d repeat this process.

How would you normally go about this?  Are we making it too complicated or does this sound reasonable?  Does the fact that we're using Team Foundation Server for our respository offer any advantages or disadvantages?


Bookmark and Share
Tags:
Actions: E-mail | Permalink | Comments (5) | Comment RSSRSS comment feed

Related posts

Comments

January 14. 2009 01:42 PM

Marcus King

Well let me first off that I am a HUGE fan of subversion over TFS, there are just too many headaches with it. However, I don't think that your problem lies in what source control system you are using. Understand that I don't have full insight into the problem and I can't make a fully informed decision but from the details you've listed out....

I think the issue is with the fact that you are needing to maintain 2 versions of the same application. Is one for development(2.0) and one already in production(1.0), are they running in parallel? What benefit is there to having MyApp1.0.0 and MyApp2.0.0? If they are two independent applications then each should really have its own trunk in source control. But once again this might not be an issue.

What maybe another solution is to see how you are using your different "levels" in the repository. You should have your Branch folder which is where all current development activities are taking place, a Trunk that is the current production codebase, and a Tags folder which is a historical snapshot of past Trunk code (contains subfolders with verison #'s).

1.Once you get finished with development you take what is currently in your Trunk folder and move it to an appropriate subfolder under Tags and name it so it includes any version information necessary (the Tags folder is a historical warehouse of every version that used to be in production i.e. Trunk).
2.You then merge the changes from the Branch folder into the Trunk folder which is only your current production code.

If you need to change a historical version of the code, in this case MyApp1.0.0 you branch it from the tags folder, make the changes, then merge it back into the Tags folder. That way your "current" code MyApp 2.0.0 Branch is unaffected. Each branch should maintain it's own historical information, thus you would have one branch for the Tags version of MyApp1.0.0 and one Branch folder for the current Production MyApp2.0.0 code. I know with subversion at least when you merge changes from your branch to trunk it is a oneshot change, it doesn't include all of your historical changes that were present in the branch, just the diff between old trunk and the new merged changes.

What concerns me is you made a comment 2. Continue developing "My App 2.0.0" in the trunk and it threw up a flag as you should never do development in the trunk, I'm guessing it was a mistake though. I know this maybe a review of already known information to you, sorry if it is.

Marcus King

January 22. 2009 06:39 AM

Speed Dating NYC

I agree with Marcus King. I don't see a reason to running a version 1.00 and a version 2.00 concurrently. I think that this actually would hinder further focus on future development.

Speed Dating NYC

January 26. 2009 11:36 PM

Ian Suttle

Thanks for the comments guys. I think we're ultimately getting at the same things here with changes in terminology. Although, I admit the "tags" comment is totally clear to me. Do you have any references I can read for further info?

Ian Suttle

February 6. 2009 04:22 AM

Eric Walker

The popular approach for developing with a version control system with reliable and safe branching and merging (ie you don't want to kill yourself each time yourself you attempt it) is to develop new features in branches, and then when those features stable and have passed QA, they are merged to the trunk which contains the latest "stable" version of the code.

This is an example from the Subversion manual about branching and merging:
http://svnbook.red-bean.com/en/1.1/ch04s04.html

Their description:

To complete our running example, we'll move forward in time. Suppose several days have passed, and many changes have happened on both the trunk and your private branch. Suppose that you've finished working on your private branch; the feature or bug fix is finally complete, and now you want to merge all of your branch changes back into the trunk for others to enjoy.

Eric Walker

February 17. 2009 12:06 PM

Marcus King

Thanks for the comments guys. I think we're ultimately getting at the same things here with changes in terminology. Although, I admit the "tags" comment is totally clear to me. Do you have any references I can read for further info?

Here is a link to a resource that is geared toward subversion but in reality the concepts apply to any source control system. I would advise listening to the audio clip and read the page, the video may not apply to you.

http://polymorphicpodcast.com/shows/subversion/

Marcus King

Comments are closed