In a general sense, for long term projects that may have multiple releases during the products life cycle and require support of previous products, what is the best way to handle product versions and branching of the code base?

In a more specific sense, assume that proper distributed version control is in place (i.e. git) and that the teams are small to large in size and that developer may be working on multiple projects at once. The major issue that is being faced is that there is a contractual obligation to support old versions as they existed at the time which means that new development can not patch old code (Microsoft Office products could be an example of this, you only get patches for the feature year you own).

As a result the current product versioning is a touch convoluted as each main product has multiple dependencies, each with their own versions which may change between annual releases. Likewise, while each product has its own repository, most of the work is not done on the main source trunk but rather on a branch for that years product release with a new branch being made when the product is released so that it may be supported. This in turn means that getting a product's code base isn't a simple matter as one might think when using version control.

  • 2
    Without more information on the products, projects and organisation of the development team(s) it's going to be very difficult to provide an answer to this that isn't hedged with caveats.
    – ChrisF
    Jan 11, 2012 at 13:19
  • @ChrisF - I'm working on some background but I'm pretty sure other developers hang out here as well so I need to protect the innocent/guilty.
    – rjzii
    Jan 11, 2012 at 13:19
  • 2
    See also programmers.stackexchange.com/q/126731/11575 Jan 11, 2012 at 13:27
  • Your best bet would be to check other questions - like that linked to above - and then ask for the bits that they don't cover.
    – ChrisF
    Jan 11, 2012 at 13:29
  • @ChrisF - Yes, I've been burning through some of the other questions and queuing up some reading based on them but the don't get me all of the way there yet. Odds are I'm going to be editing this question a lot as time goes on. The biggest issue that we are running into is providing support for previous builds which is precluding using the trunk for version milestones that others have mentioned for git.
    – rjzii
    Jan 11, 2012 at 13:37

5 Answers 5


How much (and what kind of) structure you need depends a lot on what you want to be able to do. Figure out what you can't live without, what you want to have, and what you don't care about.

A good example set of decisions might be:

Things we can't live without:

  • be able to reconstruct any past release at any time
  • be able to maintain multiple supported major versions of the product at any time

Things we would like to have:

  • be able to perform ongoing major-feature development (for the next major release) without worrying about branch merges
  • be able to perform maintenance updates to past releases

Things we can live without:

  • automated backporting of changes from current work to past releases
  • never interrupt major feature development even for a few days or a week at at time

If the above were your goals, you could then adopt a process like this:

  1. Do all development work on the trunk of your VCS ("master" in git)
  2. When you are close to a major release, halt major feature development, and focus on system stability for a week or so
  3. When the trunk seems stable, create a branch for this major release
  4. Major feature development can now proceed on the trunk, while only bug fixes and release preparation are allowed on the branch
  5. However, all bug fixes to be made to the branch must first be tested on the trunk; this ensures that they will also be present in all future releases
  6. Create a (VCS) tag on the branch when you are ready to release; this tag can be used to recreate the release at any time, even after further work on the same branch
  7. Further maintenance releases to this major release (minor releases) can now be prepared on the branch; each will be tagged before release
  8. In the mean time, major feature development geared toward the next major release can continue on the trunk
  9. When you get close to that release, repeat the above steps, creating a new releases branch for that release. This allows you to have multiple major releases, each on their own branch, in supported status at the same time, with the ability to release separate minor releases against each.

This process won't answer all of your questions -- in particular, you will need a process in place to decide what fixes can be made to a release branch, and to ensure that bugs are not fixed on a release branch first (such fixes should always be tested on the trunk where possible). But it will give you a framework in which to make such decisions.

  • +1 However, I would add that source control is only part of your environment. I would take a VM snapshot on any build server(s) and also a snap shot of a development environment, so you can go directly to a real build environment when you need to. Feb 7, 2012 at 7:25
  • 2
    I would go along with all of this, except for point 5. When you make a bug fix on a branch, you should only be concerned with getting that branch working properly. Once the bug fix has been tested on that branch, then you can merge the bug fix to the trunk, or to the branch for a newer version. Then test it again, and change whatever you need to change there. (continued) Feb 8, 2012 at 7:42
  • 1
    For example, if version 4.3 is being developed on the trunk, and you have to fix a bug in version 4.1.x, then fix the bug on the 4.1 branch, test it on the 4.1 branch, merge it to the 4.2 branch, test (and possibly fix) it on the 4.2 branch, merge it to the trunk, then test (and possibly fix) it on the trunk. Feb 8, 2012 at 7:42

"Long term" is an indicator that you need versioning, but it does not implicate any specific versioning and branching strategy. The more interesting question is how many product lines or major version lines you want to support (which depends on the contract with your customers). You will at least need one branch for every product line / major version line for which you have a maintenance contract.

On the other hand, it depends on your team size. If you have a big development team, with different people working on different features in parallel, you will obviously need more feature branches than if you have team of one or two people. If you are working with some bigger team, you should consider using distributed version control, which makes parallel working on different branches (and reintegrating them later into the trunk) much more efficient.

  • Version control is in place (git) but there are some disagreements in regards to how to handle component versions (likely to be a separate question) and product versions. Currently each product release is given a codename and new branch in the repository is created which means that new code is quite remote from the main trunk which isn't even being used in some products.
    – rjzii
    Jan 11, 2012 at 12:59

Git is a version control tool - it manages versions of files. What you are after is a configuration management tool. Theres pleantly of these avalible, but mostly at high $$$ from the likes of IBM.

Version control tools provide branching and tagging, which enables rudementy configuration management without additional tool support, hence menay developers do not understand the difference. Your needs probably extend beyond what GIT is designed to do.

I am not aware of, but am certain it will exist, a CM tool addtion for Git.


This question seems to be very similar to another question that I answered recently.

In short, this sounds more like a product design and distribution problem more than a version control/branching problem. Of course, it's easy for me to say that and harder for you to fix if you are already neck deep in the problem.

Without knowing in greater detail the specifics of your particular problem. In general however, if I had multiple versions of products based on a code base that had a large amount of shared code between products, If it was feasible I'd look to refactoring products in a way that would make them more modular, and to ensure that the modules themselves would not require additional branching of code. I'd also look at my deployment model, to see if there was a better means to support my customers while still keeping much of the code base unified. Where specific customer customization is required, greater granularity of the modules might be needed to reduce the amount of duplicated code in the system.

It's not an easy task, but fixable in stages if you manage the job well, and if you can schedule the work so that you don't need to "upgrade" everything all at once.


Main headache for keeping different release branches, creating the build pipeline and maintaining the environments. Once a release branch is there, dev team has to build and deploy the changes in a specific environment. Also, need to keep an environment for development.

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Sep 5, 2022 at 0:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.