> On 29 Jul 2020, at 14:59, Thomas Grainger <tagr...@gmail.com> wrote: > >> Why? Something like a tox environment running against the latest pytest >> prerelease (or pytest master even) plus a scheduled build job should totally >> suffice, no? > > -1 on depending on unpined deps in CI this causes the default branch > to fail and blocks all contributions until it is resolved > Creating a pr (in pyup.io) gives one point of discussion if a release > fails and does not block any other prs > Thomas Grainger > We are talking about libraries here (pytest plugin) and we have different views.
If you care to keep your "CI/CD" green at all cost, you pin everything and hide the fact that a newer version of a dependency does not work with your master code. If you care more about finding bugs with your CI/CD, you are likely wanting to test unpinned deps too. There is no perfect approach, each one has pros and cons. I personally prefer the 2nd, with the note that if the external incompatibility lingers unresolved for long, I switch the CI/CD job to non-voting (still running but not preventing merges). /sorin _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
