packaging and versioning
- instead of using
devDatewe could use
Nis the number of commits since the last tag, e.g., running
dune-commonwhich contains the number of commits since the
N=3948in this case). This would avoid any issue with being restricted with the possible package uploads. If we switch to an automatic upload via github this will become even more of an issue since the
devDateversion would be taken up by github (or github would fail if someone else manually uploaded).
- perhaps we should discourage manual uploads completely. It would be easy to trigger the CI/CD on github if one wants a new release. That might be an alternative to automatic uploads.
- we have to think again what version restriction we want to use in the
setup.pyfile for the packages. I now had the issue that I needed to fix a bug in
dune-femleading to a
dev20210524version. That correctly installed pulling the
dev20210522version of the core modules. Then I ran
pip install dune-fem-dgwhich has
dune-femas requirement and that led to a downgrade of the already installed
dune-femwhich I didn't notice - except that the bug I fixed was back again. We decided on this versioning because otherwise I couldn't have installed
dune-femat all since it would require
dev20210524of the core modules which I didn't build. Again with uploading packages via github CI/CD this could be avoided since all packages would always be updates simultaneously.