After a quiet week of beta 2 being available, and not hearing from anyone, I released coverage.py 5.0 on Saturday.

I’ve been through this before, so I knew what would happen: people with unpinned requirements would invisibly upgrade their coverage version, and stuff would break. Coverage.py is used by many projects, so it was inevitable.

Saturday afternoon was quiet. Sunday I heard from two people. Then Monday, people came back to work to find their continuous integration broken, and now I’m up to 11 issues to deal with.

It remains difficult to get people to provide instructions that are specific enough and detailed enough for me to see their problem. A link to your broken CI build doesn’t tell me how to do it myself. A link to your repo is confusing if you then add a commit that pins the old version of coverage to prevent the problem, forcing me to dig through your history to try to find the old commit that was broken. And so on.

Of course, this is nothing new, but it drove home again how hard it is to extract good information from distracted and annoyed users. If anyone has good examples of issue templates that get people’s attention and guide them well, point me to them!

While dealing with the issues, I came up with two new techniques, interesting enough to deserve their own blog posts:

• Fancy console output in GitHub comments
• Pytest trick: subsetting unknown suites

Needless to say, fixes are underway for a coverage.py 5.0.1 to be released soon.