The main reason you introduce the branch is to isolate development efforts.
So, it really depends on what you consider most important for isolation:
- promotion effort for a given release (which isolates the commit at this stage of the promotion: testing, integration, or prod / hotfixes)
- release efforts (which will include unit testing, integration, production phases all one by one)
Advancing the code allows you to simultaneously advance your release efforts (you develop n + 2 when testing n + 1 and support n).
While Branch per Release allows for a simpler sequential development cycle, where you basically test and maintain n when developing n + 1.
Regardless of the chosen strategy, you need to refer to the synchronization step between n and n + 1 (what and when do you combine the evolutions from n to n + 1?):
- With the help of Code-Promotion you can unite at different stages.
- With Branch for Release, you usually merge from only one release into the current development status for another version.
Thus, the Code-Promotion strategy means more branches, more merging and more restrictions in the history that are stored and isolated in these branches.
But it also means more environment for configuration and management.
The Branch Per Release is simpler (assuming you know that what you're working on will actually be part of the next version).