What are some guidelines for supporting multiple versions of a project?

Question

I have a project in which we start v1 and begin work on v2. I'm afraid that in the next few months we will see bug fixes and minor changes to functions in v1, some of which we will need to flip to v2, some of which we will need a separate one. (We need to support the core set of v1 functions, but fix any errors as they are found.)

We are using SVN at the moment. I considered switching to Git, but I'm a little reluctant to change tools. Besides this opportunity, what common strategies and best practices make it possible to simplify the management of this situation?

Update: Everyone suggests that I deploy the code in Subversion. It was so obvious to me that I thought it was implied in the statement “we use SVN”. Obviously not. :) I'm going to see Mercurial and Bazaar, as well as Git. Anything else?

Answer 1

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

• In the trunk, save the latest version - not necessarily stable.
• Whenever you need to separate a new major version from there, go to, say, 2.0, and you can save both the latest version and stable versions in the same repository.
• If you find changes in branch 2.0 that need to be merged into a trunk, you can do this without any problems.

Answer 2

we use TFS, but for your specific problem the solution will be very similar: create a new branch.
[Depending on the application environment used, apparently not Microsoft]
We have benefited from TFS because:

• You can do merges between branches [unreasonable merges]
• You can work with workitems, [for bugtracking]
• With the support of sharepoint, you can have documents, test scripts can live together on one portal.
• With powershell scripts you can have night machines

Answer 3

For different versions, it is best practice to save the named versions in a subfolder called tags. (SVN documents recommend that you have a folder for trunks, tags, and branches for each project).

Whenever you release a version, copy the trunk to the tag folder and give it a name. This version can live, and bug fixes can be made separately and combined back and forth.

SVN docs in repository layout:

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

Answer 4

You must use SVN to mark v1 code. Thus, you can create a separate code branch to support corrections of this code base.

Answer 5

Have you considered branching your trunk and developing v2 in the second branch after the v1 branch is frozen? If you are fixing bugs in the v2 branch that affect v1, and you want to post an update / patch for v1, just merge these specific changes back into the v1 branch from the v2 branch.

All of this is great in SVN, but it's much easier to manage branches with a tool like Mercurial or Git. I can’t tell you whether to switch it or not, because I don’t know your company or code base, but this is something to consider if you can repeat this situation that occurs repeatedly in the future when you release more versions.

Answer 6

Using git, you can use the following approach:

Your git repository may have the following branches. Each patch branch contains a feature release that must be supported.

master - version: 3.0.0 (latest release) \ dev - version: 4.0.0 (next release) |\ | hotfix-1.x - version: 1.0.1 (current hotfix 1.x) \ | hotfix-2.x - version: 2.0.1 (current hotfix 2.x) \ hotfix-3.x - version: 3.0.1 (current hotfix 3.x) 

Corrections:

Fixes are fixed in hotfix-1.x and merged up in hotfix-2.x and from there to fix-3.x.

hotfix-1.x → hotfix-2.x → hotfix-3.x ...

Corrections can also be transmitted using the git cherry pick command from hotfix-3.x to hotfix-1.x (if necessary). With the cherry-pick command, you can select one fixed one and apply it in another branch. git will also detect moved and renamed files and still apply this change correctly.

You can also add release branches parallel to patch branches in order to prepare releases in these branches (omitted in this example). This is useful if you do not want to block patch branches for new commits. Please check out gitflow if you want to know more about the details of patches and releases.

Feature Releases:

New features are based on the dev branch and merged back into the dev branch after completion. A new patch branch is created for each new release version.

Steps:

• Merge changes with the current patch on dev
• Merge function returns back to dev
• Create a new patch branch from dev
• Release the new patch .
• Merge with the master

Notes:

I think the main branch is no longer very important when you decide to keep your patch branches. I believe that the general gitflow scheme works so that you delete the patch branches and release the branches as soon as you are done. All issues must be labeled and therefore available.