The short answer is "yes, almost"...

A bit longer answer...

After merging to master, you could just tag with release number and delete the release branch. When we started this new process, we actually kept tags and branches to see how things evolve and what will be the most common use.

Example when keeping a branch became very helpful.

We had 9 apps, one of them was very small (over-glorified form) and it was 2 major versions behind since no one was working on it actively. At one point, we found a security issue and we had to patch it...

The best way would be to upgrade this app to the latest 9.xx.xx version and release, but we had a major UI change in between and that would require a few days of work, rather than 15 minutes. So instead...

1) we could take master at the tag, create new release branch, make the change and push only to this app. We would need some artificial release branch to do that. It breaks the normal approach and would require extra attention from the team. Tags could be confusing as they are out of order now.

2) we took the release branch used back then (for example release/7.1), make the change, build another version from the same branch and push to this app only + merge the fix to master. Done, follows the usuall process, nothing new or different.

Why keeping branches is helpful:

- easy to scan and see all releases and switch between them, see what went live and what was abanden. Looking for tags is a bit harder.

- We can easily upgrade old branch or use it for testing, especially when we discover something got broken a while ago and we don't know exactly where.

- It's easy to revert a release. At any time, I can just say "crap, we made a mistake, I will revert one minor /major version". All without affecting the natural release flow.

My suggestion at the end - do both!

Keep branches (it's not expensive or messy).

Keep tagging as sometimes it's more convinent.

But if you release older code, you already have release branches and the flow that won't create headaches.