- Issue created by @quietone
- 🇬🇧United Kingdom catch
Generally I'm in favour of backporting the test improvements because it helps modules support multiple branches of core with no code changes.
However that has also been hard with performance tests where the tests themselves that rely on the APIs differ between the branches - to the point where we gave up backporting some changes to 10.x
e.g. FooTest is added in 10.3 and 11.0, FooTest diverges from the 10.x version in 11.1. FooTestBase gets a new improvement in 11.2 - now the changes to the test itself in 11.1, that can be updated to the new API in 11.2, aren't backportable to 10.3. So you end up having to make a separate backport MR with either only the test API addition, or the API addition and also refactoring the 10.x version of the test.
- 🇺🇸United States xjm
Is the text proposal just this?
Testing API additions should be backported
That's not grammatically parallel with the existing sections. We would want to add a bullet with just the nominal phrase ("testing API additions").
Also, they're already allowed in minor releases. The idea would be to allow them in not only maintenance minors, but possibly also the patch branch also. So we would add it to that third section.
We might want to qualify it somehow, e.g.:
- non-disruptive testing API additions
Regarding #4, maybe that's an additional bullet for maintenance minors:
- other easily backported test improvements
(...or something; there might be a better version of that.)
- 🇺🇸United States xjm
Again, for point 1 in the IS, I think it should go under patch releases rather than minor releases. Or that's what we're proposing for review, anyway. Non-disruptive testing API additions are already allowed in normal minors as they fall under the category of "new APIs or API improvements with backward compatibility".
- 🇺🇸United States xjm
Oops, I missed a tag (for testing topic maintainer review).
