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
