[release] How do you make a library update official?
I just uploaded changes ([85417] and [85418]) to Boost.Rational that fix the two major problems showing up on the regression tests. How do I get them on the official distribution? I know we don't read off the SVN-trunk directly; there's some staging area first. (That's why the shippers occasionally declare a code freeze deadline.) I know we have a "release" branch, but I'm not sure that's still being used. I want to blaze ahead making tweaks to Boost.Rational, but not if you can't "make official" a non-HEAD change-set. Even if I miss the deadline for these other tweaks, I want the two I just already did to be in Boost 1.55. Daryle W.
I just uploaded changes ([85417] and [85418]) to Boost.Rational that fix the two major problems showing up on the regression tests. How do I get them on the official distribution? I know we don't read off the SVN-trunk directly; there's some staging area first. (That's why the shippers occasionally declare a code freeze deadline.) I know we have a "release" branch, but I'm not sure that's still being used.
It was used for the 1.54 release (and releases before that). I'm not sure whether it will be used for 1.55. There was talk of having switched to git by then, but I'm not sure whether that is still the plan. Regards, Nate
From: zeratul976@hotmail.com Date: Thu, 22 Aug 2013 05:09:56 +0000
I know we have a "release" branch, but I'm not sure that's still being used.
It was used for the 1.54 release (and releases before that).
I'm not sure whether it will be used for 1.55. There was talk of having switched to git by then, but I'm not sure whether that is still the plan.
So I can do a SVN-merge into the "release" branch now and that'll still work. Now I have to look up how to merge.... Daryle W.
Le 23/08/13 10:21, Daryle Walker a écrit :
From: zeratul976@hotmail.com Date: Thu, 22 Aug 2013 05:09:56 +0000
I know we have a "release" branch, but I'm not sure that's still being used. It was used for the 1.54 release (and releases before that).
I'm not sure whether it will be used for 1.55. There was talk of having switched to git by then, but I'm not sure whether that is still the plan. So I can do a SVN-merge into the "release" branch now and that'll still work. Now I have to look up how to merge....
Daryle W.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Move to the release directory and do cd boost/your_lib svn merge "^trunk/boost/your_lib" cd ../../libs/your_lib svn merge "^trunk/libs/your_lib" This should merge all the modifications of your_lib from trunk. Best, Vicente
On Fri, 23 Aug 2013, at 01:16 PM, Vicente J. Botet Escriba wrote:
Move to the release directory and do
cd boost/your_lib svn merge "^trunk/boost/your_lib"
That should be: svn merge "^/trunk/boost/your_lib" But it probably won't work in this case, as earlier changes won't be marked as merged, so it will try to merge them as well. The easiest thing to do is probably to specify the revisions to merge. At the root of a release checkout: svn merge -c85417 -c85418 "^/trunk/"
On Fri, 23 Aug 2013, Daniel James wrote:
On Fri, 23 Aug 2013, at 01:16 PM, Vicente J. Botet Escriba wrote:
Move to the release directory and do
cd boost/your_lib svn merge "^trunk/boost/your_lib"
That should be:
svn merge "^/trunk/boost/your_lib"
But it probably won't work in this case, as earlier changes won't be marked as merged, so it will try to merge them as well.
The easiest thing to do is probably to specify the revisions to merge. At the root of a release checkout:
svn merge -c85417 -c85418 "^/trunk/"
A more selective way is to merge single changes at a time. I have attached the file I'm using for that for BGL (for Linux); it has directions for use, but you will need to customize it for your library. You will need to filter out old updates manually, but you get more control over what to merge and get a file of detailed changes (log messages from changes in the trunk) to help in writing the change log. -- Jeremiah Willcock
But it probably won't work in this case, as earlier changes won't be marked as merged, so it will try to merge them as well.
The easiest thing to do is probably to specify the revisions to merge. At the root of a release checkout:
svn merge -c85417 -c85418 "^/trunk/"
A more selective way is to merge single changes at a time. I have attached the file I'm using for that for BGL (for Linux); it has directions for use, but you will need to customize it for your library. You will need to filter out old updates manually, but you get more control over what to merge and get a file of detailed changes (log messages from changes in the trunk) to help in writing the change log.
And just to say that if your goal is "make the release branch the same as Trunk", then something like: svn merge release/libs/yourlib@HEAD ../trunk/libs/yourlib@HEAD release/libs/yourlib svn merge release/boost/yourlib@HEAD ../trunk/boost/yourlib@HEAD release/boost/yourlib adjusting paths to release and trunk as required. HTH, John.
On Aug 21, 2013, at 9:44 PM, Daryle Walker <darylew@hotmail.com> wrote:
I just uploaded changes ([85417] and [85418]) to Boost.Rational that fix the two major problems showing up on the regression tests. How do I get them on the official distribution? I know we don't read off the SVN-trunk directly; there's some staging area first. (That's why the shippers occasionally declare a code freeze deadline.) I know we have a "release" branch, but I'm not sure that's still being used.
Oh, it's definitely being used. The "release branch" is where releases get built from. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Daryle Walker wrote:
I just uploaded changes ([85417] and [85418]) to Boost.Rational that fix the two major problems showing up on the regression tests. How do I get them on the official distribution? I know we don't read off the SVN-trunk directly; there's some staging area first. (That's why the shippers occasionally declare a code freeze deadline.) I know we have a "release" branch, but I'm not sure that's still being used.
I want to blaze ahead making tweaks to Boost.Rational, but not if you can't "make official" a non-HEAD change-set. Even if I miss the deadline for these other tweaks, I want the two I just already did to be in Boost 1.55.
I follow this procedure https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromd... for those directories which correspond to the library which I personally maintain. It's kind of a pain - but I don't do it very often. Note that this dovetails well with my normal practice: a) I maintain a local copy of the boost release. I update this once in a while so my local copy corresponds to the NEXT expected release. b) I switch the directories of the libraries I maintainto the trunk. In most cases this amounts to two directories - one from "boost" and one from "libs" c) I run my tests on this setup. This gives me an indication of how my tests will work when finally merged into release. In my view testing against the whole boost trunk creates random noise when some error is checked into the trunk. d) when my tests pass, I commit to the trunk. From time to time I merge trunk to release using the above procedure. Robert Ramey
Daryle W.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
From: ramey@rrsd.com Date: Fri, 23 Aug 2013 11:45:55 -0800
I follow this procedure
https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromd...
for those directories which correspond to the library which I personally maintain. It's kind of a pain - but I don't do it very often.
I kind-of followed that page; when I tried without any revision numbers, the merge-test reported a tree conflict in an unrelated library while my changed files weren't reported. I did a merge-test again, with revision numbers ([85417], update test code for C++11's numeric_limits; [85418], fix narrowing conversion error in less-than; and [85434], correct for MSVC not accepting "not" for "!".) and got the expected results, except for a maybe-conflict for "libs/rational/test/rational_test.cpp", since multiple change-sets affect that file. (The other file for these changes is "boost/rational.hpp", which is affected in one change-set.) I performed an actual merge, and that conflict-warning never happened. A diff from the pre-changed archive had the expected results, so I committed the merge on the release branch as change-set [85441]. Since it's my first time touching the release branch, can some expert check that I didn't accidentally fry some meta-data (or some other damage)? Daryle W.
participants (8)
-
Daniel James -
Daryle Walker -
Jeremiah Willcock -
John Maddock -
Marshall Clow -
Nathan Ridge -
Robert Ramey -
Vicente J. Botet Escriba