Ginkgo Release Process
The purpose of this page is to elaborate a safe procedure for releasing Ginkgo code. The aim is to cover important topics for releasing the code and ensuring there is less mistakes when going through this process by following a sort of checklist we could come up with.
This is highly recommended to ensure a good quality of the Ginkgo releases. These steps in general relate to making sure the release process goes as smoothly as possible and that we reduce the amount of problems for our users and contributors as much as possible.
In order to assist in the release process and center the team's focus towards the release, it is important to create a new milestone for the release and an issue to manage the release process. At some point in time it should be possible to add an issue template for a release-type of issue, but we do not have one yet.
To create a milestone, click on the milestone link from the issues's page, or go here. The process is fairly simple and needs to further comments. Once this is done, add the newly created milestone to every issue and pull requests which should be part of the release.
The way milestone work, as issues are closed and pull requests merged it will gradually get closer to 100%. Whenever all other issues are finished and the milestone reaches 100%, it is time to proceed with the rest of the release process. Some of the following steps can still be started in parallel, but be sure to retest them when all the merge requests are merged!
We currently have the tag "bug" in order to track bugs present in Ginkgo. The following links allow you to see the list of bugs:
Before releasing, it is important to deal with bugs is some way. The first obvious way is to fix them before releasing if that is possible. This depends on the time constraints and the complexity of the bug. If the bug cannot be fixed in time for the release, then add to the Known Issues page the existing bugs that we know of. It can be as simple as a link to the relating issue but could also take a sentence for context and severity.
We have support for calling our test suite with the valgrind tool thanks to CMake. It is important to check that there is no major memory access issues before releasing. Failing to do so may cause severe problems for our users.
To run these tests, use the following procedure. First build Ginkgo as usual, ensure everything is on. Then launch the tests and finally the memchecks one :
# In the ginkgo folder
cmake -G "Unix Makefiles" -H. -BDebug -DCMAKE_BUILD_TYPE=Debug -DGINKGO_DEVEL_TOOLS=ON \
-DGINKGO_BUILD_TESTS=ON -DGINKGO_BUILD_REFERENCE=ON -DGINKGO_BUILD_OMP=ON \
-DGINKGO_BUILD_CUDA=ON
cmake --build Debug
cd Debug
ctest
export OMP_NUM_THREADS=2 #limit the number of threads due to slow valgrind
ctest -T memcheck
This will output a summary of the test results (memcheck passing or not and the amount of defects) in the command line. The details are available in a directory such as Testing/<timestamp> and Testing/Temporary. There should be among other files a lot of files in the form of MemoryChecker.xx.log. Go through all of them and check which sort of errors were returned and for which tests.
