My team is working on a product, which for business reasons needs to be released on a regular schedule. An issue has arisen where we want to do development in parallel for the upcoming release, as well as the 'next' release. This is to become standard practice, so it's not as straightforward as cutting a feature branch for the new work. We'll continually have 2+ teams working on different releases of the same product.

Is there an SCM best practice for this sort of arrangement?

  • I don't get it - if I understood you correctly, you use feature branches. When you don't want a feature in release 42, only in release 43, you just don't reintegrate the feature branch into the trunk from which release 42 is build. Where is the problem?
    – Doc Brown
    Sep 18, 2012 at 20:21
  • @DocBrown - If I understand your question: Because a release involves more than a single feature? There needs to be some integration/build/test location for the future release.
    – Telastyn
    Sep 18, 2012 at 21:02
  • working with feature branches and holding back the features until the 'next' release works for an arbitrary number of features. Of course, when something is integrated into the trunk, you should integrate it immediately back into each active feature branch, that will make the final reintegration of that feature back into trunk painless. If you really need an additional integration/build/test location, then why not just create an "integration branch for the next release"?
    – Doc Brown
    Sep 19, 2012 at 6:05

3 Answers 3


I've seen stuff like this get managed on open source projects, though admittedly I have limited experience.

imagine this branching structure.

-- R0 ---> R1 --->---> R2 --->--->- R3


--->---> trunk --->--->--->--->--->--->


-->--->---> version next --->--->--->

In this scenario, you take snapshots of the trunk every time you make a release, and this becomes the final code for that version. Version next is a clone of the trunk at some arbitrary point in time. As new features are developed, they can be pushed into the trunk whenever management decides they are ready.

ALSO: Ideally you would include which SCM in the description of the question, because things like perforce behave very differently from git.

  • 1
    I would add to this by saying the majority of coding should be done on trunk (or feature branches that get merged into trunk). Then you can "cherry pick" the changesets needed from trunk onto your release branch as needed. Almost all SCMs support cherry picking. Sep 19, 2012 at 2:41
  • We're working with TFS.
    – Telastyn
    Sep 19, 2012 at 11:33
  • @ssgriffonuser I agree.
    – coder543
    Sep 19, 2012 at 13:16
  • @Telastyn alright. I don't know anything about Microsoft's source tools. I used Visual Studio Express back years ago, but that's it. I'm more into git... but then again, I don't need tight integration with VS.
    – coder543
    Sep 19, 2012 at 13:17
  • @ssgriffonuser want to put that into a more elaborated answer? In my experience, cherry picked changesets tend to lead to more user error. Invariably, there's some 'previous' changeset to the one you want with things you don't.
    – Telastyn
    Sep 19, 2012 at 13:25

One interesting alternative I read about recently is what Martin Fowler calls a Feature Toggle. The idea is that you can avoid branching by just turning off the features that have some code but aren't ready yet.

Whether it's worth it depends on how painful each option is, and Fowler is speaking from an Agile perspective in which it's important that everyone feels free to refactor, which branching can inhibit.


I believe this post would be of help to you.

From experience, it also helps not to think of version numbers until the actual release build has been made. In other words, don't associate your branch names with version numbers.

The reason you don't want that is that it gives you the flexibility to change the order of release of the versions you're working on. It also means that you don't end up with branches with version numbers in their names ("rel_0_9", "rel_1_0" ).

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.