Timing the Release branch

Question

Part of the team is working on next release / sprint, the rest working on testing and bug fixing the previous sprint before a release to production.

The part working on next release wants the branch now, the other part wants it as late as possible because they will have to start merging fixes as soon as we branch.

I don't like making anybody wait to commit because we haven't branched yet. I also don't like wasting peoples time when they don't understand merging. (And SVN doesn't merge renames)

Any opinions or suggestions? Thanks

Note:

This was a worse problem in the past because we were using tortoisesvn 1.6 with a 1.4 repo which prevented the GUI from doing branch / merge operations. So I removed that impediment by upgrading the repo. It should atleast now be easy for the team members to merge.

Answer 1

I highly recommend Git/Mercurial for these sorts of problems. :)

But since I know thats not an option, I'll just say that there really is no 100% great answer to these types of problems. In general, I tend to prefer not branching until as late in the process as possible, as branching and merging with CVS/SVN tend to be heavyweight processes. The longer that you can defer the branch process, the better off you are in many ways. But as the team working on new features knows, this can only go on for so long... at some point the cost of delaying new features outweighs the benefits of deferring the merge.

Where I am now, this often results in a branch 1-2 weeks (or sometimes even less) before the release of a new version. But the exact time always varies based upon the specific pressures driving releases, and new features in upcoming releases.

Answer 2

Branching does not have to be a painful process in SVN - especially with the latest versions of TortoiseSVN and the SVN client. It requires some knowledge of the VCS and the repo, but that should be required for any software developer.

Something to think about is how much new code and how many modifications are likely to occur in each phase of development. Typically the sprint/release phase generates a heftier change set than the bug-fix stage. This implies that it's more sensible to branch immediately and merge the smaller number of bug fixes in as they come. In most cases, waiting to branch results in a messier merge.

Branching early also gives your bug fixes more exposure as they can be exercised by the sprinting developers during the unit and functional tests for new features. More exposure = better bug-free fixes.

Answer 3

Once you go into feature freeze for a release you have to do the branch so that the team working on the next release don't continue to break the one you're trying to put to bed. Trying to delay a branch further than this is just going to cause more problems.

If you use feature branches then this gets easier. All fixes happen in trunk, you keep a RC branch where you will release from and you can do wholesale merges from trunk to it ahead of doing testing releases. Features branches merge from trunk and only get merged back into trunk when the feature is ready. Although this sounds like it results in a lot more merging, it keeps all of the merges very simple.

This is similar to the workflow that you would get with a DVCS, except that all of the branches are in plain sight rather than spread around developer's machines.

Answer 4

Another point for your consideration:

Consider keeping the progressive code (the code most actively used is assumed to be the one heading towards new-newer-newest releases) on the TRUNK. Branch out from the HEAD (or a previous baseline release if you have tagged it ) for the use of the bugfixer team. They can keep fixing the bugs and merging from trunk periodically to grab updates from the latest development if they wish.

The new release work on the other hand goes on the TRUNK and the TRUNK can be earmarked to always represent what is in the "current" or the "production" environment. If you want to grab back the fixes made for the previous releases into the curent release, you can merge back from the bugfix branch to the TRUNK.

This model can be iterated after the next release tag as well.

In my experience this helps minimise merges as the bug fixes will be less in number so this means lesser files to merge back to the TRUNK as and when required. In most(i say most not all :-)) cases, the number of dev folks on bugfixing will be less in number so again this means smaller number of files needing merges.

HTH.

Answer 5

Branch as late as possible.