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
  • 572
  • 6
  • 17
  • 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 08 '14 at 09:36
  • as explained in [this answer](http://programmers.stackexchange.com/a/191194/31260) 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?](http://programmers.stackexchange.com/q/107884/31260) – gnat Aug 08 '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 09 '14 at 14:19
  • http://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 09 '14 at 14:32

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,354
  • 6
  • 102
  • 172
  • 1
    How do you handle updates to past releases then? I imagine you must branch off from your release tags? – Torben Gundtofte-Bruun Aug 08 '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 08 '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 08: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 08: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 08:25
  • @TorbenGundtofte-Bruun well, if trunk is unstable, is it "considered unsafe to merge from an unstable codeline into a stable codeline" (to quote yourself) when making release branches from trunk. You must trust trunk enough to create a release in the first place, just use the same testing you do on a release to ensure its fit. – gbjbaanb Aug 12 '14 at 08:36
  • Our understanding is that when the trunk is feature-complete (but not stable yet) it is safe to create a release branch because that won't make it _more_ unstable, hence no need for "trust". Any bugs should always be fixed in the "more stable" release branch first and then merged into the less stable trunk. – Torben Gundtofte-Bruun Aug 12 '14 at 08:39
  • @TorbenGundtofte-Bruun if that's the way you want to do it, that's fine. Bugfixing on trunk allows you to get the bug fix right (as it is unstable itself until proven) and then the final, proven good bugfix is merged. If you;ve ever had a bugfix that took several iterations to get right then you realise why you don't want to make bugfixes directly on Release. You create an unstable release branch temporarily. Its safer to make changes elsewhere and merge when reviewed, tested etc. You could make a branch from release for these if you prefer though. – gbjbaanb Aug 12 '14 at 10:04
  • Thank you; it's this kind of essential practical experience that we are missing! As we're all total versioning noobs we thought it would be better to not have too many branches, so we'd want to avoid a fix-branch that needs to be merged back (yes, either into trunk or into release, depending on your or my approach). "Avoiding branching" is probably another noob mistake, then? – Torben Gundtofte-Bruun Aug 12 '14 at 10:44
  • @TorbenGundtofte-Bruun I prefer a feature-branch approach, branch off trunk, make changes, then merge back onto trunk when its done, reviewed, tested etc. This can be a problem if you leave branches lying around for a long time - only create a feature branch if you intend to merge it onto trunk! The advantage is that it allows devs to work independently, without affecting others - you might ave problem when merging, but generally such problems are rare and easily fixed anyway (ie 2 devs change the same thing). Don't be afraid of branches or merging. – gbjbaanb Aug 12 '14 at 10:51
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/16363/discussion-between-torben-gundtofte-bruun-and-gbjbaanb). – Torben Gundtofte-Bruun Aug 12 '14 at 10:59