Merging feature branches to release branch instead of trunk

I have a question about two source control scenarios, both with feature branches and release branches:

• In scenario 1 feature branches are merged to the trunk.
• In scenario 2 feature branches are merged to the latest release branch.

What are the consequences of scenario 2 compared to scenario 1?

What are the possible advantages and disadvantages of both scenarios?

More details of the two scenarios:

• all development is done in feature branches
• branching is alwa开发者_高级运维ys done from the trunk

Scenario 1 (similar to what is described in this SO-answer):

• feature branches are always merged to the trunk
• a new release branch is created from the trunk, when preparations start for a new release
• after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk and newer release branches
• changes to the trunk are merged to all feature branches

Scenario 2:

• feature branches are always merged to the newest release branch
• a new release branch is created from the trunk, when the current release branch no longer accepts new features and preparations start for final release
• after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk
• changes to the trunk are merged to all feature branches and the newest release branch

Since branching is all about isolation (see "When should you branch), the difference between the 2 scenarios is the role you want the main branch trunk to have:

• Scenario 2 is more adapted to a static role: trunk would be the representation of what is in production (and the occasional hot-fixes needed to be merge back to current feature and next-release branch)

• Scenario 1 is more suited for a dynamic role: trunk is the integration for various feature, release branches being made from there to consolidate the features which will actually be part of the next release.