You see its this lack of flexibility and clarity that naming a branch release brings. I refer you to my earlier suggestion of including the release number in the branch name to remove ambiguity and make it easier to create for example 1.35.1 whilst release 1.36.0 is in progress since it is clear where fixes should go. Can I also suggest that people try out using git-svn for cherry picking their commits. From memory you'd clone the repository as I outlined in an earlier thread, then do: git checkout -b release release gitk --all Then find the commits you want to cherrypick, right click and select cherry-pick. Exit gitk Push back to svn: git svn dcommit On 6/21/08, Matthias Troyer <troyer@phys.ethz.ch> wrote:
On Jun 20, 2008, at 6:16 PM, Rene Rivera wrote:
Hm, is there an email delay problem with the list server?
Matthias Troyer wrote:
I'm a bit confused about the release process - should we have the changes on the trunk or the release branch? I assumed the trunk but maybe I need to move them to the release branch?
You need to merge to the release branch as has been mentioned in the past <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromde...
.
I have actually waited for a new release branch to be created for 1.36, since I had always assumed that that branch was for the 1.35.1 release. Well, it seems that unless we still get permission to mere changes 1.36 will go out with the same bugs as 1.35
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Sent from Google Mail for mobile | mobile.google.com