We have lately had problems with applying HydPy 5.0.1 because some of its dependencies have evolved, harming some HydPy features. So, this seems like a good time to improve our release strategy.

Currently, we specify the dependencies in requirements.tx (for development), in pyproject.toml (for building the source and binary distributions), in make_hydpy_installer.cfgt (for making the installer for Windows), and in setup.py (for applying HydPy as a site-package).

We do not set specific version numbers in any of these files. Regarding setup.py, this is standard practice. According to the Python documentation: It is not considered best practice to use install_requires to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades.

I see two options: We could pin all dependencies to a specific version, which is convenient from the developer's perspective but inflexible from the user's perspective. Or we could leave the versions undefined and update releases like HydPy 5.0 regularly to ensure they work with the latest version of their dependencies.

I tend to favour the second option, which means we would need to cherry-pick the relevant commits from the master branch from time to time. If we do it regularly, the effort should be manageable.

Theoretically, we could automatise checking that releases are still fully functional with the latest dependency versions by repeating the last continuous integration runs every week or so. But maybe it is sufficient to wait until someone encounters a problem.