What are some best practices for maintaining multiple versions of a project?

Question

I've got a project where we're rolling out v1, and beginning work on v2. I'm afraid that we're going to see bug fixes and minor feature changes to v1 over the next few months, some of which we're going to need to roll into v2, some of which we're going to need to keep separate. (We need to maintain v1's major feature set, but fix any bugs as they're found.)

We're using SVN at the moment. I've considered switching to Git, but I'm a little reluctant to change tools. Aside from that possibility, what are some general strategies and best practices to make managing this situation as easy as possible?

Update: everyone's suggesting I branch the code in Subversion. That was so obvious to me that I thought it was implied by the "we're using SVN" statement. Apparently not. :) I am going to look at Mercurial and Bazaar as well as Git, though. Anything else?

Answer 1

Using SVN, the best you can do is branch your repository:

• In the trunk, keep the latest version - not necessarily a stable one.
• Whenever you need to separate a new major version from there, branch to, say, 2.0 and you can keep both latest version and stable versions in the same repo.
• If you find changes in branch 2.0 that need to be merged into the trunk, you can do it seamlessly.

Answer 2

You should use SVN to tag the v1 code. That way you can create a separate branch of the code to support fixes to that code base.

Answer 3

Have you considered branching your trunk and doing v2 development on the second branch once the v1 branch is frozen? If you fix bugs on the v2 branch that affect v1 and you'd like to release an update/patch for v1, just merge those specific changes back to the v1 branch from the v2 branch.

All of that is perfectly doable in SVN, but it is much easier to do branch management with a tool such as Mercurial or Git. I can't tell you if it's definitely worth switching or not since I don't know your company or codebase, but it's something to consider if you can forsee this situation arising repeatedly in the future as you release more versions.

Answer 4

For different versions the best practice is to store the named versions in the "tags" subfolder. (SVN docs recommend you have a trunk, tags and branches folder for each project).

Whenever you release a version, copy the trunk to the tags folder and give it a name. That version can live on and bug fixes can be made to it separately and merged back and forth.

SVN docs on repository layout:

http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html

Answer 5

we are using TFS, but for your specific problem, the solution will be quite similar: create a new branch.
[Depending the application environment you are using, apparently not Microsoft]
We have benefited from TFS because:
1. You can do merges between branches [baseless merges]
2. You can work with workitems, [for bugtracking]
3. With sharepoint support, you may have documents, test scripts can live together happily at one portal.
4. With powershell scripts, you can have nightly automerges