Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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 '12 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 '12 at 13:19
2  
See also programmers.stackexchange.com/q/126731/11575 –  AProgrammer Jan 11 '12 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 '12 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 '12 at 13:37

4 Answers 4

up vote 17 down vote accepted
+50

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.

share|improve this answer
    
+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. –  Neal Tibrewala Feb 7 '12 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) –  David Wallace Feb 8 '12 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. –  David Wallace Feb 8 '12 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.

share|improve this answer
    
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 '12 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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