2

Say that we've decided on following a "release-based" branching strategy, so we'll have a branch for each release, and we can add maintenance updates as sub-branches from those.

Does it matter whether we:

  1. develop and stabilize a new release in the trunk and then "save" that state in a new release branch; or
  2. first create that release branch and only merge into the trunk when the branch is stable?

I find the former to be easier to deal with (less merging necessary), especially when we don't develop on multiple upcoming releases at the same time. Under normal circumstances we would all be working on the trunk, and only work on released branches if there are bugs to fix.

What is the trunk actually used for in the latter approach? It seems to be almost obsolete, because I could create a future release branch based on the most recent released branch rather than from the trunk.

Details based on comment below:

  • Our product consists of a base platform and a number of modules on top; each is developed and even distributed separately from each other.
  • Most team members work on several of these areas, so there's partial overlap between people.
  • We generally work only on 1 future release and not at all on existing releases. One or two might work on a bugfix for an existing release for short periods of time.
  • Our work isn't compiled and it's a mix of Unix shell scripts, XML configuration files, SQL packages, and more -- so there's no way to have push-button builds that can be tested. That's done manually, which is a bit laborious.
  • A release cycle is typically half a year or more for the base platform; often 1 month for the modules.
Community
  • 1
Torben Gundtofte-Bruun
  • 592

1 Answers1

1

That's true - if you have multiple 'trunks', each one representing a release, then you don't need a single trunk. In fact, trunk is an arbitrary name for a 'master' branch anyway (eg in the Microsoft docs for TFS they recommend using a thing called 'Main').

But there is a good reason for developing elsewhere and using the release branches just for 'finished' code. It increases the opportunities for quality, as you can develop independently and merge your final, tested, code to several release branches. For example, you decide to update a component to a later release (you've found a security bug in it, say). You can make the change on trunk and merge that change to all your release branches instead of making the same change repeatedly. Generally this approach works, though it will get awkward as your trunk moves further away from older releases.

If you use a single trunk, you can also use feature branches which are great. Make changes to a branch, get them reviewed, and when you consider them done, merge to trunk. Lots of development can be performed independently without interfering with other developers work.

So I tend to work in a single trunk, fed from feature branches, and tagged as a release periodically, with occasional patches applied to the release as needed.

gbjbaanb
  • 48,749
  • 7
  • 106
  • 173