<p>We have a software product that evolves at the rhythm of clients' needs and of a more general roadmap.</p>

<p>Because we are in a SCRUM project environment, it happens very regurlarly that a new feature makes its way to the product, and then we are confronted with the choice of:</p>

<ul>
<li>implementing this feature in an already released branch (not really the point of having a branch, then)</li>
<li>making a new branch - but then we have a branch every three weeks, and it is just not maintanable anymore</li>
</ul>

<p>Not releasing the new feature is not an option, the clients don't want to wait for a long term milestone plan to get the features they want, and it's not always faisible to move the feature in a client module - sometimes we need to change the core of the product...</p>

<p>Has anyone any feedback on a good practice given those kind of constraints ?</p>

A new branch like( 'new_feature_branch') is there to materialize a
development effort
which is not compatible with the current branch (like 'release_branch')
So if your current release_branch is not very active, you can use it for the new feature (provided you define a label
before
developing this new feature, in case you need to cancel that process and go back to the state previous this new feature)
Making a new branch can be a good solution provided it is merged back on a regular basis (every 3 weeks) on the release branch, and then left out. It is especially recommended if you have some activities on the release_branch (like some hot bug-fixing). then the two efforts need to be kept separated.
Basically, it all comes down to your
merge workflow
definition.
Leave comments if you want me to detail some options you feel I did not address enough in depth.