2

This question already has an answer here:

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.

marked as duplicate by Bart van Ingen Schenau, ChrisF Aug 23 '14 at 16:35

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • What you do it source control depends on your needs. It would provide useful context if we knew whether everyone is working towards the release or are there devs working on post release stuff? Do you have effective regression testing, how long is the build-deploy-vefify cycle? (eg if lots of devs are working on post release and there's a lot of inertia in the testing avoid option 1 with a passion) – Nathan Cooper Aug 8 '14 at 9:36
  • as explained in this answer to another (possible duplicate) question, one shouldn't mix conflicting purposes of the branch. If it's intended for release, then only changes proven as necessary for release should go there. Doing development in release branch would rather serve conflicting purpose. See also: To branch or not to branch? – gnat Aug 8 '14 at 11:13
  • In what way do you see that as a duplicate, @gnat? I studied that question before posting this, and I don't see much overlap. We don't have conflicting purposes in the above mentioned release branches. We're trying to figure out in which branch to work but we're not going to work in both! – Torben Gundtofte-Bruun Aug 9 '14 at 14:19
  • meta.stackexchange.com/a/194495/165773 (I also explained why I think so in prior comment, "one shouldn't mix conflicting purposes" etc) – gnat Aug 9 '14 at 14:32
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.

  • 1
    How do you handle updates to past releases then? I imagine you must branch off from your release tags? – Torben Gundtofte-Bruun Aug 8 '14 at 11:00
  • @TorbenGundtofte-Bruun sometimes we do, but for some components that never change (eg the openssl bugfix of a few months ago), the same patch could be applied to them all. Generally we don't need to as we only work on the "current release" except for critical, one-off patches. – gbjbaanb Aug 8 '14 at 11:11
  • Your answer makes a lot of sense, and it's the way we're headed now. But isn't it also considered unsafe to merge from an unstable codeline into a stable codeline, which is what you'd be doing when you merge a fix from trunk into a release branch? It makes sense, I just want to learn to do things right. – Torben Gundtofte-Bruun Aug 12 '14 at 8:11
  • @TorbenGundtofte-Bruun trunk is stable, surely. Releases are based off it, therefore it must be stable or all your codelines will be unstable. – gbjbaanb Aug 12 '14 at 8:14
  • Ah, that's where I was on a different track. Our assumption is that main development is in the trunk and when it's feature-complete we create a release branch for stabilizing and subsequent packaging, from which the changes are merged back into the dev trunk to contribute to future versions. So our release branches would always be more stable than our dev trunk. – Torben Gundtofte-Bruun Aug 12 '14 at 8:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.