On 07.05.2013 22:30, [email protected] wrote: > Author: brane > Date: Tue May 7 20:30:34 2013 > New Revision: 1480061 > > URL: http://svn.apache.org/r1480061 > Log: > * installer/README.rst: Bring the note about using the --system-site-packages > option with virtualenv from the 0.5 branch back to trunk.
I happened to notice that the installation instructions on trunk were out of date with regard to the latest release. That made my hair stand on end. :) I suggest that the normal process for updating release branches should be to make the change on trunk /first/, and then merge it onto the relevant release branch. If we do it this way, mishaps like this one cannot happen; and it's even more important to do this for bug fixes than documentation fixes. Subversion has long followed this process to good effect. The back-porting procedure is documented here: http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization and I propose all of that page is useful reading for BH developers. Notice that on the Subversion project, we maintain a STATUS file on each release branch which contains a list of proposed back-ports, and all such proposals need approval from several committers. I'm not suggesting BH should require such a formal approach for now, but it /would/ be a good idea to track backports somewhere -- if for no other reason than to make it easier to maintain release notes. -- Brane P.S.: Needless to say, for Subversion, we have a daemon running that periodically looks at the "approved" section of the STATUS file and automatically merges the backports for us. :) -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
