> 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 On Wed, 29 Jul 2020 at 14:56, Sorin Sbarnea <ssbar...@redhat.com> wrote: > > Yes, I would call 6.0.0 a blazing success. I was expecting far more problems. > > > On 29 Jul 2020, at 14:21, Florian Bruhin <m...@the-compiler.org> wrote: > > > > FWIW things aren't nearly as bad as you claim them to be. Just because not > > *all* issues were caught during the pre-release, that doesn't mean *none* > > were. > > I put users in two categories: consumers and contributors (power users, people > raising bugs, PRs or plugin creators). It is almost guaranteed that those in > first > category fail to find time/interest to test pre-releases, most of them prefer > to > complain about that new release broke their jobs. Yep, I seen/hear it, tried > to educate them (nothing specific to pytest). > > In the end if they failed to put a ceiling on pytest version is their fault. > > Still, it goes bit more complex when it comes to pytest plugins, which IMHO > they must have CI/CD jobs testing pytest so they avoid conflicts. If they do > not > plan to support new versions they can do the ceiling pytest version (which I > do not > recommend). > > > -1 on further fragmenting people by having even more communication channels. > > That'll lead to the exact opposite of what you probably want, as you'll > > reach > > *less* core maintainers than via an already established and widely used > > channel. > I agree that fragmentation is bad. I hope that questioning if a classic > mailing list is the best medium was not seen as something bad, especially as > the newer mediums do not prevent mailing list mode usage. > > I already seen how much damage chat platform fragmentations can do, with > projects where communities scattered across a dozen of platforms and never > knowing which one is active. > > > On Wed, Jul 29, 2020 at 01:16:06PM +0100, Thomas Grainger 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? > > > > Yes, it is very easy to schedule jobs and get emails when things get broken > with almost any CI/CD system, including Travis. > > Testing pre-releases is also very easy to implement, here is an example > that implement the "devel" testing idiom for pytest-html: > > https://github.com/pytest-dev/pytest-html/pull/320 > > I used this for very long time with projects that were notorious on breaking > on new releases. It helped me prevent bugs in upstream and also gave me > time to refactor the code in such way that it would not break with the new > release. > > Cheers, > Sorin > _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
