[1.35] Release branch status

Hi, The release branch was created some time ago, and Interprocess and Intrusive were just copied from the trunk since they are new libraries for Boost 1.35. Meanwhile, I've been committing some fixes and improvements to the trunk branch. Both release and trunk branch regression seem to be ok. I still see several issues in the release branch and I don't know when we plan to release 1.35 so I was wondering if I could update Interprocess+Intrusive of the release branch with the current trunk code. If so, this merge is something I'm allowed to do with SVN (I read something about a python script some weeks ago) or the release manager is the only person who should do this? Regards, Ion

Ion Gaztañaga wrote:
Hi,
The release branch was created some time ago, and Interprocess and Intrusive were just copied from the trunk since they are new libraries for Boost 1.35. Meanwhile, I've been committing some fixes and improvements to the trunk branch. Both release and trunk branch regression seem to be ok.
I still see several issues in the release branch and I don't know when we plan to release 1.35 so I was wondering if I could update Interprocess+Intrusive of the release branch with the current trunk code.
If so, this merge is something I'm allowed to do with SVN (I read something about a python script some weeks ago) or the release manager is the only person who should do this?
It is OK for developers to merge low risk changes into the release branch, although not for much longer. To qualify as a low risk change, it should: * Be a fix rather than a new feature. * Have been committed to the trunk for several days, and the trunk regression test results inspected to make sure the change isn't causing unexpected breakages. * And you should watch the release tests (which are stalled until Sunday) to make sure it doesn't break the release branch. If you haven't done Subversion merges before, remember that just doing the merge doesn't change the repository. A commit is required to change the repository. So after you do the merge, but before you do the commit, check out the merge carefully to make sure it worked as desired. If it isn't right, revert and start over. I personally find it convenient to have two working copies checked out. One is the current trunk, where I do most development, and the other is branches/release, where the merge is done. --Beman

Beman Dawes wrote:
It is OK for developers to merge low risk changes into the release branch, although not for much longer.
To qualify as a low risk change, it should:
[good stuff]
Thanks for your kind reply Beman. I'll follow the process you recommend, now that regression test results are back on trunk.
--Beman
Regards, Ion
participants (2)
-
Beman Dawes
-
Ion Gaztañaga