aboutsummaryrefslogtreecommitdiff
path: root/Docs/source/developers
diff options
context:
space:
mode:
authorGravatar Axel Huebl <axel.huebl@plasma.ninja> 2021-02-18 20:15:52 -0800
committerGravatar GitHub <noreply@github.com> 2021-02-18 20:15:52 -0800
commit03650f39bbef3da49f2a4623da93d0b6b6ce11b7 (patch)
tree0a12f15924fbc203e41bfa1dcbfd2f1cb660eb5b /Docs/source/developers
parent04c5a487106127d5f4a24a5c6f6c1c5bc8153c3c (diff)
downloadWarpX-03650f39bbef3da49f2a4623da93d0b6b6ce11b7.tar.gz
WarpX-03650f39bbef3da49f2a4623da93d0b6b6ce11b7.tar.zst
WarpX-03650f39bbef3da49f2a4623da93d0b6b6ce11b7.zip
Tool: update AMReX dependency (#1710)
* Tool: update AMReX dependency We currently pull the `development` branch of AMReX in CMake builds. This is problematic in central workflows: - checking out a release might not compile - manual intervention is needed by users - builds are not as reproducibile as they could be - CI fails in a surprising wary in WarpX if a temporary bug is lands in AMReX' `development` Instead, we can bump the AMReX requirement periodically in a PR. This migh be the case when we: - need new features or bug fixes - do a release Manual updates guarantee that we see problems with updates from AMReX in the moment they are introduced - during a PR that changes the dependency to AMReX. * Tool: update PICSAR dependency See AMReX' updater description. * Docs: Dependencies & Releases Update and add workflows. * PICSAR & AMReX: Bump Version to HEAD Bump the PICSAR and AMReX versions to the latest head. Executed with: ``` ./Tools/Release/updateAMReX.py ./Tools/Release/updatePICSAR.py ``` * Python Tools: Cleanup * Fix typos Co-authored-by: Luca Fedeli <luca.fedeli@for.unipi.it> Co-authored-by: Luca Fedeli <luca.fedeli@for.unipi.it>
Diffstat (limited to 'Docs/source/developers')
-rw-r--r--Docs/source/developers/developers.rst2
-rw-r--r--Docs/source/developers/release.rst55
-rw-r--r--Docs/source/developers/workflow.rst32
3 files changed, 56 insertions, 33 deletions
diff --git a/Docs/source/developers/developers.rst b/Docs/source/developers/developers.rst
index 94777c4e0..a1ffb7c65 100644
--- a/Docs/source/developers/developers.rst
+++ b/Docs/source/developers/developers.rst
@@ -25,5 +25,5 @@ Our Doxygen API documentation in classic formatting `is located here <../_static
testing
documentation
performance_tests
- workflow
+ release
checksum
diff --git a/Docs/source/developers/release.rst b/Docs/source/developers/release.rst
new file mode 100644
index 000000000..336c19ca6
--- /dev/null
+++ b/Docs/source/developers/release.rst
@@ -0,0 +1,55 @@
+.. _developers-release:
+
+Dependencies & Releases
+=======================
+
+Update WarpX' Core Dependencies
+-------------------------------
+
+WarpX has direct dependencies on AMReX and PICSAR, which we periodically update.
+
+The following scripts automate this workflow, in case one needs a newer commit of AMReX or PICSAR between releases:
+
+.. code-block:: sh
+
+ ./Tools/Release/updateAMReX.py
+ ./Tools/Release/updatePICSAR.py
+
+
+Create a new WarpX release
+--------------------------
+
+WarpX has one release per month.
+The version number is set at the beginning of the month and follows the format ``YY.MM``.
+
+In order to create a GitHub release, you need to:
+
+ 1. Create a new branch from ``development`` and update the version number in all source files.
+ We usually wait for the AMReX release to be tagged first, then we also point to its tag.
+
+ There is a script for updating core dependencies of WarpX and the WarpX version:
+
+ .. code-block:: sh
+
+ ./Tools/Release/updateAMReX.py
+ ./Tools/Release/updatePICSAR.py
+
+ ./Tools/Release/newVersion.sh
+
+ For a WarpX release, ideally a *git tag* of AMReX & PICSAR shall be used instead of an unnamed commit.
+
+ Then open a PR, wait for tests to pass and then merge.
+
+ 2. **Local Commit** (Optional): at the moment, ``@ax3l`` is managing releases and signs tags (naming: ``YY.MM``) locally with his GPG key before uploading them to GitHub.
+
+ **Publish**: On the `GitHub Release page <https://github.com/ECP-WarpX/WarpX/releases>`__, create a new release via ``Draft a new release``.
+ Either select the locally created tag or create one online (naming: ``YY.MM``) on the merged commit of the PR from step 1.
+
+ In the *release description*, please specify the compatible versions of dependencies (see previous releases), and provide info on the content of the release.
+ In order to get a list of PRs merged since last release, you may run
+
+ .. code-block:: sh
+
+ git log --since=<last-release-tag> | grep -A 3 "Author: " | grep -B 1 "\-\-" | sed '/--/d' | sed -e 's/^ /- /'
+
+ 3. Optional/future: create a ``release-<version>`` branch, write a changelog, and backport bug-fixes for a few days.
diff --git a/Docs/source/developers/workflow.rst b/Docs/source/developers/workflow.rst
deleted file mode 100644
index 226cf77f3..000000000
--- a/Docs/source/developers/workflow.rst
+++ /dev/null
@@ -1,32 +0,0 @@
-.. _developers-workflow:
-
-Workflow
-========
-
-Create a new Github release
----------------------------
-
-WarpX has one release per month.
-In order to create a release, you need to:
-
- 1. Create a new branch from ``development`` and update the version number in all source files.
- There is a script for that, so you can do:
-
- .. code-block:: sh
-
- cd Tools/DevUtils/
- ./update_release.sh # This replaces the old version number with the new one.
-
- Then open a PR, as usual. NOTE: do not merge this PR before step 2 is completed.
-
- 2. Click the ``Draft a new release`` button at https://github.com/ECP-WarpX/WarpX/releases and follow instructions.
- Please specify the compatible versions of dependencies (see previous releases), and provide info on the content of the release.
- In order to get a list of PRs merged since last release, you may run
-
- .. code-block:: sh
-
- git log --since=<date> | grep -A 3 "Author: " | grep -B 1 "\-\-" | sed '/--/d' | sed -e 's/^ /- /'
-
- where ``<date>`` is the date of the last release, say ``2020-05-01`` if the last release was on May 1, 2020.
-
- 3. Optional: create a ``release-<version>`` branch, write a changelog, and backport bug-fixes for a few days.