At my current workplace there are some projects that when preparing a release will

  1. backup the current RELEASE branch by making a branch from it with the current date (this isnt technically required, so this is optional. It does happen more often but its not 100% of the time)
  2. delete the current RELEASE branch
  3. take the latest DEV branch (DEV is the same as master, where developer topic/feature branches are PR/CI'd into) and make a new RELEASE branch from it
  4. build the artifacts for release from the RELEASE branch

The release branch is short lived as it is deleted after a branch is made from it as a copy. It ceases to exist. At some point in time later, the DEV branch is branched into a branch called RELEASE, but this is a new release branch. Call it a rename if you think thats what it always equates to, but the topic was not about if it was a rename or not.

Are there any well known (and explained) branching and releasing strategies that fit this kind of pattern? I havent been able to locate any that are close, but perhaps I'm not searching for them correctly.

  • 1
    Where in the described scenario is a "short lived" relase branch?
    – Doc Brown
    Sep 19 at 16:23
  • 3
    FWIW, the above strategy does IMHO fit well to trunk-based development. When it comes to create a new release, the latest RELEASE branch has to be replaced by the current DEV branch. An alternative strategy would be to add a tag to the DEV branch and build the release artifacts from the tag.
    – Doc Brown
    Sep 19 at 16:34
  • "short lived" as in it gets deleted the next time artifacts need to be produced. The replacement is created from dev no matter how complete the work is in the dev branch (3 of 5 tasks for a user story feature completed? Oh well, time to release it!). To me deleting the release branch breaks the ability to draw a line from a program in some environment back to the specific source code that went into it. I think the only reason these projects are operating this way is because they dont want to bother with merging stories that have all the tasks completed.
    – StingyJack
    Sep 20 at 4:38
  • 2
    @StingyJack, in steps 1 & 2 of the process you describe, I see a rename action of the old release branch before creating a new one. That is a valid strategy to keep old releases available while the latest greatest release can always be obtained from the branch named RELEASE. Sep 20 at 7:16
  • 2
    @StingyJack: what is the point of merging into release when this actually results in a replacement of the latest dev branch? And as Bart van Ingen Schenau wrote, the first two steps are nothing but a "rename", so there is nothing lost or "short-lived".
    – Doc Brown
    Sep 20 at 18:28

The process described almost feels like an anti pattern, but there must probably be some reason why the powers that be wanted to follow it. Having a short lived release branch makes me uncomfortable because one may need to go back to a stable build or may need to go back to a previous build for troubleshooting.

In my opinion experience, the cleanest option is to freeze the dev branch and the merge it into the existing release branch and then create a new release branch with the date + release number (or tag the release branch with a date and release number). Either of these options will allow you to go back to a stable build or go back to a previous release for troubleshooting.


The first step (create a branch just to timestamp it) seems pointless. You can tag/label the current release branch with the date instead and be done with it.

The rest makes sense in an environment where relatively serious development and/or rework is taking place in dev. Yes you can build usable software at any time but there are likely some issues with it. If you build from dev, do a quick test and find some issues, you want to be able to fix them just for that release. "Fix" could be disable the work in progress someone on the team is doing. Or it could be a small bug. While you are fixing your release you do not want other people to push new stuff thus creating a moving target.

This approach allows development to continue uninterrupted rather than have the whole operation adapt to some intermediate release moment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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