Comments on: Developing in branches, releasing from trunk

By: Yannis

Yannis — Tue, 30 Sep 2008 16:03:03 +0000

I can see the point of the process if you say the business needs separation and visibility of features developed, but I think it’s going to cause you problems when it’s time to merge - and as you point out it will make major refactoring an impossibility. I really like development done on trunk, because then I know that there is something that works. What you describe means different versions of the software with slightly different features that work, but may end up being very difficult to manage.

Let us know how it goes!

By: Developing in streams, releasing from streams « Software Configuration Management

Thu, 25 Sep 2008 17:26:57 +0000

[…] I read the following blog, Developing in branches, releasing from trunk about a software configuration management development process that was constrained and […]

By: Rags

Rags — Tue, 16 Sep 2008 12:35:54 +0000

That makes sense - especially the bit about choosing at the end which features go into the release.

By: znachor

znachor — Mon, 15 Sep 2008 17:02:20 +0000

Rags, the dependent tickets would be grouped by creating a new parent ticket and assigning all the children tickets to that. I can sort of see now why it is so important to separate different coding streams. It is more business requirement than a good software engineering practice. It happens quite often that a given feature is withdrawn just before release or a work on separate features is done in parallel and then decision which feature are going to be released happens last minute. Then the way with multiple branches merged into release branch sounds reasonable. Of course if we don’t count the “merging hell”!

By: Rags

Rags — Mon, 15 Sep 2008 13:54:10 +0000

Have a look at http://weblogs.java.net/blog/tball/archive/2008/09/distributed_scm.html as well.
Also have a look at Mercurial for a distributed source control system which is good with merging (or so I’ve heard).

By: Rags

Rags — Mon, 15 Sep 2008 13:42:54 +0000

Why can’t you just create your release branch at development time, point your CI build to it and everybody check in there? There is no real “Continuous Integration” to be performed at the end of the development cycle anyway, after everyone’s branches have been merged together. You are only trying to “fix” your build at that point in time. If you had one common development branch, then the stated problem with refactoring is also a non-issue.

How do you handle different tickets where one ticket depends on the functionality provided by another ticket? Do they get clumped together on the same branch?

By: Julian Simpson

Julian Simpson — Sun, 14 Sep 2008 10:02:21 +0000

I like the idea of being able to reconcile JIRA tickets with the code in the branch, but my gut feeling is that you’d have some serious merge pain if each feature gets developed in a private branch. The classic CI approach of doing the bulk of development in the trunk and then branching for each release has the advantage of little merges and constant integration( see http://www.build-doctor.com/2008/09/branching-do-it-like-this-and-nobody.html).

I’m trying to convince the developers to use Perforce jobs at my work. Then we just need to reconcile those to a Rally story and we can see what features ended up in a release.

By: Robbie

Robbie — Fri, 12 Sep 2008 20:48:48 +0000

I think you’d call how we work in our group, optimistic check-ins. The trunk should always be in a releasable state, meaning a good build. However, we consider it worth the risk of breaking the build to check into the trunk. This may be a result of the longer release cycles, but I’m quite happy to work this way.