...
The responsibility of merging changes from the trunk to the various branches is the responsbility of the release manager for the branch in question. To be clear if you are committing changes to trunk do not merge your changes into any of the release branches.
Warning | ||
---|---|---|
| ||
I really support this approach, I think it makes the most sense of any of the strategies out there, however the downside of this approach is how it scales over time. As time goes on and the deviation between the functionalties implemented on the trunk and when they are released increases, the chances of multiple desired functionalities overlapping in some part of the code increases...eventually causing the premature partial release of some functionality. Use of something like that svnmerge.py script that uses svn properties to note what has been merged where and when will address this to some degree, but some system where we know that F(A) references X files and F(B) references Y files...and when we are looking to promote F(B) but not F(A) we can doublecheck that we are not partially promoting F(A)...since svn merges will not pull out the F(A) changes if they are in the same file as F(B). I see this a lot in volatile development environments coupled with exceedingly tight release cycles. |
Releases
Creating a release branch
...