I am not a developer myself so please bear with me. We are providing solutions for various customers and it is common to have a situation like this:

  • Our customer has a version 1.1, and wants us to provide maintenance and support for this version
  • At the same time, they request us to develop another version (let's say 1.2) also with new features, that will get piloted in field (so both versions will be in production at the same time).

How can this mainline development work, there isn't just one mainline and for example fixes done on 1.1 (in support) need to be also merged into 1.2. but not the other way around with features.
The reason I ask is that our upper management heard that agile, CI, CD etc. is the thing and that we must do it.

  • Let me see if I understand your question: you want to have 1 version control repository (e.g. Git), and you have 2 related code bases to maintain: V1.1 and V1.2. You're wondering what happens if you change, say, main.c to fix something in V1.1 - whether this will break V1.2. Is this about right? If so, I'll post an answer.
    – Lawrence
    Commented Jul 23, 2018 at 14:04
  • @Lawrence Well basically, this is the situation we have: one version is in production and needs continuous support, another version in the pilot (also needs support). And our management now pushes for trunk-based development. Commented Jul 23, 2018 at 17:20
  • Unfortunately, it is impossible to guess what your management has in mind at this point. Agile, CI, CD work just fine with multiple branches, please give more details on requirements.
    – Basilevs
    Commented Jul 24, 2018 at 17:43

3 Answers 3


You clarified in comments:

Well basically, this is the situation we have: one version is in production and needs continuous support, another version in the pilot (also needs support). And our management now pushes for trunk-based development.

Trunk-based development has all the ongoing work done on the trunk. There can be work done in branches, but these are never committed back to the trunk. Over time, your V1.1 and V1.2 will diverge.

See the following pictorial comparison from trunkbaseddevelopment.com:

Short-lived vs long-lived feature branches

If you can arrange for features to be coded to interfaces, then changes from the trunk can be more easily retrofitted into the branch. Otherwise, you're essentially maintaining 2 code bases from the time of the split.

  • Do we keep branches and perform no merges? How does it align with a requirement to have exactly one branch?
    – Basilevs
    Commented Jul 24, 2018 at 17:40
  • @Basilevs Trunk-based development doesn’t restrict you to one branch - it’s more that the focus is on developing the trunk and avoiding large merges. See the little cycles at the bottom of the second figure - litttle merges are fine. Your V1.1 becomes a legacy release that never merges back to the trunk; you keep working on the code and eventually split off a V1.2 into its own release branch that never merges back, and so on.
    – Lawrence
    Commented Jul 24, 2018 at 23:32

In theory you it doesn't. The defining feature of this kind of flow is that you always deploy the new features straight away. Whereas you need NOT to deploy features.

However, having said that there would be nothing stopping you branching from a particular release say v1, doing fixes on it and deploying from that branch to your v1 customers.

Again, in theory you could merge your v1 branch back into master to get the bug fixes in v2 and onwards. But in practice I think you will find that the versions diverge very quickly and it will be easier to just write the fix once per version.


What you are looking for is called release. It naturally exists for desktop and mobile software, where each device has its own copy of a program. It is less common for web software, because it supposed to be unique. But you can do same for web application: set up a server https://prod.app.example.com/, and set up release branch v1.1 to deploy there, and set up a server https://preview.app.example.com/, and make release branch v1.2 deploy there.

There are a number of ways to manage release branches. I like these 2 links: thunk based model, other models. They are opinionated, but have nice pictures so that you can pick your way.

  • Not sure I follow. When considering mainline/trunk development, I should have just one trunk and the code should be releasable after each commit. But I do not believe it can happen if we have to maintain more versions at the same time. Commented Jul 23, 2018 at 12:15
  • 1
    @EzoelaVacca Why not? Just because you commit releasable code to the trunk doesn't mean the other branches stop working - those are based on older code, and that version of the code doesn't change.
    – Lawrence
    Commented Jul 23, 2018 at 12:27
  • @Lawrence But we need two different releasable code bases - one for the version in production (fixes), and one for another version (in pilot). Commented Jul 23, 2018 at 12:46
  • 1
    @EzoelaVacca If you maintain 2 branches (one of which could be the trunk), you'd have 2 releasable code bases, right?
    – Lawrence
    Commented Jul 23, 2018 at 12:47
  • @Lawrence Yes, but this isn't one trunk, as I understand it. Commented Jul 23, 2018 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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