John Hunter wrote:
Since we already have a bug in the 98.4 release, we can anticipate needing to do a bugfix release accumulating all the bugs we fix in the next week (presuming we don't discover any critical bugs which would require us to push out a fix earlier). To make sure we achieve maximal stability, I have created a 98.4 maintenance branch which should only get bugfixes. All other development can proceed apace on the trunk.
svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\ <https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\>
v0_98_4_maint mpl98.4 --username=youruser --password=yourpass
Mike, can you advise on the procedure for doing merges from the new branch to the trunk. In particular, what I am confused about is how to inform svn-merge that I want to merge from 98.4 branch and not 91.4 branch.
You can add a new branch for the trunk to "track" using "svnmerge.py init", e.g., from a working copy of the trunk:
> svnmerge.py init https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_4_maint
property 'svnmerge-integrated' set on '.'
After doing a "svn commit" on this, this merge tracking is available to everyone, so there's no need for anyone else to do the "svnmerge init". I'll go ahead and commit this now.
Now, the trunk is tracking two branches for merges, 0.91.x and 0.98.4. This means that when doing a merge, one must manually specify which branch to merge from using the "-S" parameter. You can see which branches are available for merge using "svnmerge.py avail":
> svnmerge.py avail
svnmerge: multiple sources found. Explicit source argument (-S/--source) required.
The merge sources available are:
So to merge from 0.98.4, one would type:
> svnmerge.py --source v0_98_4_maint merge
(rather than the "svnmerge.py merge" we used to do).
The tracking for 0.91.x can be removed with the "svnmerge.py uninit" command, e.g.:
> svnmerge.py --source v0_91_maint uninit
This will make merging slightly easier, (since the -S parameter is not required), and it is generally good practice in the long run to not keep extra branches lying around. I'm happy to make this change, but thought I'd run it by you first -- it means we're effectively abandoning the 0.91.x series, or at least saying any bugfixes to it will have to be manually brought over to 0.98.x.