Context: The software development company I work for develops an application which is released with SemVer versions. Typically customers use the last 2-3 minor releases, so for an example if the latest released version is 3.6 there is still a relevant user base using releases 3.5 and 3.4. For these versions, we guarantee that bugs are fixed and (in special cases) features developed for the next, upcoming version are backported.

Technically we implement this by having a develop branch where new features are developed and one branch per supported version (ie support/3.5 and support/3.4). There are two actions that are often performed:

  • Implement a bugfix either based on the support branch. This branch will merge into the supoprt-branch and create a new patch (ie 3.5.1). What is left to do is to cherry-pick this bugfix in at least the develop branch (so it is fixed in the next release) and potentially other support branches. The alternative is to do the inverse, starting a bugfix on the develop and cherry-picking it into the support branch.
  • Backport a feature to an older version: Sometimes customers can't update to the latest version. Thus, given enough capacity, the pull requests implementing a new feature on develop are backported into the support branch, tagging a new patch. We do know that this in combination with SemVer is not ideal (given the argument that SemVer is not for products), though this is not the focus of my question here.

Personally, I have often been the person to backport features via cherry-picking, sometimes those team members creating a feature will also backport their own work.

In addition, when creating a new minor release, I often create a release candidate-branch (release-branch according git GitFlow). I then run tests for a couple of days and cherry-pick bugfixes or minor changes that are happening on develop. Finally, a release is tagged and this branch becomes the new support branch.

From the perspective of a team lead I wonder: Is there such a role as a "backporter" or a "release developer" who hase the responsibility of trying to backport/"forwardport" fixes or features? It seems that this person would have to understand Git quiet well, be able to manage conflicts and generally be able to work with code develop by others and thus potentially foreign to them.

An example which suggests that there is indeed a valid need for such roles are the backport and release teams working on Node.js (see nodejs/Release).

I am looking for the correct terms of such a role so that I can further research common team structures to support what my team is doing.

  • 6
    Is it a common task? Yes. But I've never worked in a company where it was time-consuming enough to make a whole role for it. Jan 31 at 9:23
  • In addition to what Philip Kendall said, if you're using git as your version control system, I'd expect most developers to be comfortable enough with the git operations that you describe. And working with code developed by others is part of the job. If an organization needed a specific role for this activity, it seems like that would be pointing out other problems.
    – Thomas Owens
    Jan 31 at 12:13
  • "features developed for the next, upcoming version are backported" -- this doesn't sound like SemVer at all. "Features" typically increase the minor version, so "backporting" a feature to 3.5 means "upgrade to 3.6". Jan 31 at 13:00

2 Answers 2


I don't think this a common thing. If we start with "all software" and start looking at what has to happen before you have this job, its cutting out a lot of software. At each step you lose a percentage of the whole.

  1. You have to support more than one version of your software

    Most software these days is server based. So you only really have one version at any given time, you always update your software to the latest and throw away the old versions after you have migrated off them. Customers are automatically updated.

  2. Not only do you support the old versions, but you also add features to them.

    Even if an old version is supported, it's usually just for bug fixes, security updates etc. For new features customers have to update. Companies want to sell the new version, upgrade clients and stop having to support old versions.

  3. You have to have a non modular architecture. Often software with many features is built in a modular way, so that you can select the features/modules you want and buy just those.

    In this case there is no/less "backporting" required. A new module will be developed to work with versions x, y and z and not require extra work after release.

  4. You have to have enough of this backporting work that it makes sense to have a separate team dedicated to it.

    "Cherry picking" isn't magic. As the versions diverge "backporting" a feature becomes more and more like "writing it again, but different", it would make sense to have the same team that developed/tested the feature also work on adding it to older versions, rather than a separate team.

  5. You have to have developers who are willing to accept the role.

    Given that they didn't "develop" the feature it doesn't seem like they will be getting as much credit as the first development team, by the time they release a feature for an old version that feature will already have been launched and be old news. It sounds very much like a second rate role even though the work is essentially the same.

Overall, the philosophy most companies follow is to push their customers to constantly upgrade. This generates revenue and reduces costs. If you have an important client that cant/wont upgrade for some reason, you might support them, but it means twice as much work.

If you imagine you have taken over a company that supports 10 versions of its software, you could fire the teams supporting 9 versions, get all the customers to upgrade and make significant savings. Even if 5 of those customers pay for an upgrade and 4 leave you, you will still be getting a bonus that year.

  • Some very clearly formulated points, I agree. In practice, the company I work for is in fact non-standard along some of the dimensions you list. Seems like supporting more than one version would typically be a a team effort. With multiple teams, they could rotate on working the next / supporting the previous version but then again, that would be a sign of a potentially large / complex domain that should be adressed.
    – FabianTe
    Jan 31 at 12:59
  • 1
    It seems it would be simple to just have the one team make a feature that works for all versions. Of course they would say "that will take longer", and the resource cost of supporting multiple versions will be clearly shown. Having a secondary team work on it seems like it's just a way to disguise this cost. The role seems like office politics
    – Ewan
    Jan 31 at 13:33
  • "Most software these days is server based.". I doubt that. I guess most software these days are locally installed apps for smartphones (surely with some server connection), still a local frontend on its own..
    – Doc Brown
    Feb 2 at 19:40
  • most apps have a backend or are just a website wrapped as an app
    – Ewan
    Feb 2 at 20:36
  • 1
    This answer has sparked a lot of discussions with collegues and gave me a new perspective. You answered in a structured manner so accepting your answer seems appropriate.
    – FabianTe
    Feb 8 at 10:20

Roles are normally much more general, and often enough a role name does not fully define the responsibilities associated with that role in a specific organization. If you bring specific expertise such as those you mentioned the responsibilities may even be associated with you as a person and not with the role itself.

You mention the Node.js backport and release teams. I would assume that the team responsibilities are not necessarily reflected in the role names, so each team would have a team lead, senior and maybe junior developers, and the team as a whole would have the backport and release responsibilities, with the team deciding which member is best suited to perform the actual work in a given situation. None of this needs to be in the role name.

  • This reflects how we deal with everyday-stuff. Team members backporting their own implementations and fixes. What I don't yet understand is, if there is typically a subset of members which are responsible for "crafting" the next release. Given a software with large release cycles that is a rather important task. I guess that in my context, I would simply associate these persons with the responsibility with building a release candidate and give them grant them permissions to manually build a release from the source branch.
    – FabianTe
    Jan 31 at 9:54
  • 1
    "... and other duties as assigned." -- the loophole in the job descriptions where I work. @FabianTe, I bet your job description has similar phrasing. Even if it doesn't, it is common to have all sorts of things given to the person willing or able to do the work. Jan 31 at 13:03
  • Agree. In my current lead role I am considering either changing our support strategy (fewer supported versions, more frequent, smaller updates, the whole CI/CD package) or establishing and communicating a concrete responsibility for the rather custom workflow we seem to have. Currently this is not really managed and thus a source of frustration for the usual developer who tends to prefer working on the latest develop, not supporting old stuff.
    – FabianTe
    Jan 31 at 13:14

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.