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.

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?

share|improve this question
    
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 '12 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 '12 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 '12 at 6:05
add comment

3 Answers

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 --->--->--->--->--->--->

|(clone)...../..../../...../...../../..../

-->--->---> 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.

share|improve this answer
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. –  ssgriffonuser Sep 19 '12 at 2:41
    
We're working with TFS. –  Telastyn Sep 19 '12 at 11:33
    
@ssgriffonuser I agree. –  coder543 Sep 19 '12 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 '12 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 '12 at 13:25
add comment

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" ).

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.