Backward/forward compatibility with coverage 4

[gaborbernat]

Hello,

virtualenv still wants to test with python 3.4, which translates to coveragepy 4. The idea here would be to use the fancy new features on newer pythons (e.g. dynmaic context for test suit) but still run on older/support dropped version. At the moment though coverage 4/5 cough and fail if they find any configurations that are not defined. This means that coverage.py 5 only configuration cannot be set within the config file, because that will fail run when running under coverage 4. Not all configuration can be set from the CLI though, e.g. dynamic_context, cannot be:

https://coverage.readthedocs.io/en/coverage-5.2.1/contexts.html#dynamic-contexts

Any ideas how to support such use case? Does coveragepy must fail if it finds configurations not defined? This means in practice that as soon as someone introduces a configuration that's new everyone is forced to upgrade coveragepy. Is this the intended behaviour?

[nedbat]

One option would be to keep two different rc files, for the old and new coverage versions.

There's not much we can do to make older versions less strict, that would require adding to those old branches and releasing a new version, which I would rather not do.

[gaborbernat]

Maintaining two configurations is troublesome, and hard to keep in sync. Ideally I'd prefer the patch release for 4.x to solve it. Just one release needed. Otherwise this is something to consider to add to master at least going ahead because the issue will keep manifesting with the current policy.

[nedbat]

In commit 602e210 I made these warnings instead of errors.

[nedbat]

This is now released as part of coverage 6.0.