== Users == I have rewound the branch 'next' after the release, so it will not fast-forward (just this once). If you have a local 'next' branch, you should abandon it and check out a fresh one. You can do this with
$ git checkout master $ git branch -D next # delete the old branch $ git pull $ git checkout next # revisit 'next' if you want If you are tracking 'master', 'git pull' will be sufficient. == Developers == With v3.4 tagged, we can decide what to do with the branches left over from 'next' (now in a temporary 'next-pre-3.4' that will be deleted). If they should be rebased, it's best to do it now. $ git checkout my/branch $ git rebase v3.4 $ git push -f --dry-run # should show force-update to your branch only, then remove '--dry-run' If you like everything in the branch, but there are conflicts, you can sync with v3.4 now [1]. $ git checkout my/branch $ git merge v3.4 $ git push Here is a status summary for the branches that used to be in 'next': e8577e4 2013-04-10 (karlrupp/feature-viennacl) ViennaCL: fix LOCDIR This has a simple conflict with 'knepley/remove-sieve' (below) in src/vec/vec/interface/vecregall.c b61a8fb 2013-03-15 (klaij/fieldsplit-simple-ex70) SNES ex70.c: free array returned by PCFieldSplitGetSubKSP() This example highlights a bug/feature request in fieldsplit. If it can be handled without interface changes, it should go to 'maint'. a05fad5 2013-05-12 (knepley/remove-sieve) DMPlex: remove bad "DMMESH" documentation This branch is a bit chaotic and could reasonably be rebased and have the incomplete commits squashed together. 1cf896f 2013-03-22 (knepley/solkx) SNES ex75: Added Maple verification test, and added preliminary FEM test This branch contains one commit (a9ffcdab03f) that is unrelated and made it into v3.4 in a different form (3e298deff27), so rebasing would make it cleaner. aee7f6d 2013-05-08 (prbrune/snes-npcjacobianlagging) Tests for persistent lagging of the Jacobian or Preconditioner This made changes to src/snes/examples/tutorials ex15_4 that conflict with 'prbrune/snes-npcrhsfix' (merged 2013-05-03). It should either be rebased or it should merge from v3.4. The remaining commits in 'next' have either been rebased (Karl accidentally rebased 'karlrupp/feature-viennacl' after merging it to 'next') or are commits that were made in an inappropriate place and were later cherry-picked back to the proper branch. ee5caa0 Revert "MPIUNI: Now it returns error codes correctly" 5b3707c Revert "DMPlex: fix initialization of variables in degenerate case" 607f2c0 DMPlex: fix initialization of variables in degenerate case 2786d98 Repair bad merge of 'barry/rm-xxxregisterdynamic' 2233159 ViennaCL: Updated to new AMS viewer model ec89c54 ViennaCL: Fixed includedir in viennacl.py package handler 3cdc909 ViennaCL: Applied const-correctness to functions. 9d766b4 ViennaCL: Eliminated whitespace violations, removed/fixed erroneous comments. c21fe5b ViennaCL: Device type can now be specified via command line. 67575d3 ViennaCL: Now catching the correct type of exceptions (std::exception) 19900a9 ViennaCL: Eliminated dead/unused code c2cfb21 ViennaCL: Fixed issues if size 0 is passed. bb99cb5 ViennaCL: Setting VIENNACL_WITH_OPENCL flag to enable OpenCL backend as default. 4b3d4ac ViennaCL: Added package detector for OpenCL, added OpenCL-dependency for ViennaCL. 9329d19 ViennaCL: Added MPI-implementation for AIJ matrices. 19b9568 ViennaCL: Removed seqviennacl/aijassemble.cxx (would trigger error, now uses existing fallback) dbcb10b ViennaCL: Renamed files to fulfill conventions (.cpp -> .cxx, all lowercase), removed restriction of C++ everywhere. c65bdabe ViennaCL: Added sequential AIJ matrix. 8bf5113 ViennaCL: Added MPI vectors. bff62fe ViennaCL: Removed unnecessary call to resize() at vector construction. 1737cda ViennaCL: Download of package now working. 8034546 ViennaCL: First draft, including all operations for sequential vectors. 8de993d Bug fix for MatLoad_MPIBAIJ() buffer size for rank zero read was wrong size; simplified code as well MatLoad_MPIAIJ() also This fix can also be ported back to 3.3 [1] You may remember that we normally ask branches to avoid merging from upstream. A release is an exception to this: the release should be at least as stable as the arbitrary place that you started working from, and it's a well-defined point, so it's perfectly acceptable to merge v3.4.
