From ec5f4fafbc2058ed5f1e355ab68d4fba567e1c51 Mon Sep 17 00:00:00 2001 From: Matthew Brett Date: Fri, 5 Apr 2013 00:29:35 -0700 Subject: [PATCH] DOC: more updates to release notes Add merge -s ours instructions for maintenance branch. Add reminder to do pyx file doctests. --- doc/devel/make_release.rst | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/devel/make_release.rst b/doc/devel/make_release.rst index 25380c699b..ce9f3acaa2 100644 --- a/doc/devel/make_release.rst +++ b/doc/devel/make_release.rst @@ -64,6 +64,13 @@ Release checklist * Check the examples - we really need an automated check here. +* Check the ``pyx`` file doctests with:: + + ./tools/doctest_extmods.py dipy + + We really need an automated run of these using the buildbots, but we haven't + done it yet. + * Check the ``long_description`` in ``dipy/info.py``. Check it matches the ``README`` in the root directory, maybe with ``vim`` ``diffthis`` command. Check all the links are still valid. @@ -202,7 +209,7 @@ then do you push to upstream on github. further substantial development (often called 'trunk') and another for maintenance releases. - * Branch to maintainance:: + * Branch to maintenance:: git co -b maint/0.6.x @@ -220,6 +227,12 @@ then do you push to upstream on github. Thus the development series ('trunk') will have a version number here of '0.7.0.dev' and the next full release will be '0.7.0'. + Next merge the maintenace branch with the "ours" strategy. This just labels + the maintenance branch `info.py` edits as seen but discarded, so we can + merge from maintenance in future without getting spurious merge conflicts:: + + git merge -s ours maint/0.6.x + Push with something like ``git push upstream-rw main-master:master`` If this is just a maintenance release from ``maint/0.6.x`` or similar, just