Description and how-to for maintenance operations. Some of the maintenance scripts have been moved to the pcmsolvermeta repository
Version numbering follows the guidelines of semantic versioning
To update, change the relevant field in the
We follow the guidelines of Keep a CHANGELOG
On all but the release branches, there is an
under which new additions should be listed.
To simplify perusal of the
CHANGELOG.md, use the following subsections:
Addedfor new features.
Changedfor changes in existing functionality.
Deprecatedfor once-stable features removed in upcoming releases.
Removedfor deprecated features removed in this release.
Fixedfor any bug fixes.
Securityto invite users to upgrade in case of vulnerabilities.
Updating Eigen distribution¶
The C++ linear algebra library Eigen comes bundled with the module. To update the distributed version one has to:
download the desired version of the library to a scratch location. Eigen’s website is: http://eigen.tuxfamily.org/
unpack the downloaded archive;
go into the newly created directory and create a build directory;
go into the newly created build directory and type the following (remember to substitute @PROJECT_SOURCE_DIR@ with the actual path)
cmake .. -DCMAKE_INSTALL_PREFIX=@PROJECT_SOURCE_DIR@/external/eigen3
Remember to commit and push your modifications.
Updating the copyright notice¶
You need to have access to the
pcmsolvermeta repository to update the
copyright notice. The copyright notice text is in the file
copyright_notice.txt in the
tools directory. The script
update_copyright.py will extract the text from the file, create the
appropriate header and perform the update on the files in the subdirectory
where it is invoked.
The copyright notice on top of the Config.hpp.in file needs to be manually updated!
We have two repositories one public for the release, hosted on GitHub and one private for the development, hosted on GitLab. At release time the master branch on the private repository is synced to that of the public repository.
This means that WHATEVER is on master at release time is considered ready for release. Protection of functionality happens EXCLUSIVELY by making use of branches/forks on the private repository.
You need to compile the to-be-released code and run the unit test suite. If compilation works and all unit tests are passing then the code is ready to be released:
git push Origin release
Origin has been spelled with a capital
O the reason being
that the release branch gets pushed both to the private and the public
repositories (trick explanation)
In brief, you need to have a
.git/config file that resembles the following:
[remote "origin"] url = firstname.lastname@example.org:PCMSolver/pcmsolver.git fetch = +refs/heads/*:refs/remotes/origin/* [remote "GitHub"] url = email@example.com:PCMSolver/pcmsolver.git fetch = +refs/heads/*:refs/remotes/GitHub/* [remote "Origin"] url = firstname.lastname@example.org:PCMSolver/pcmsolver.git url = email@example.com:PCMSolver/pcmsolver.git