System information

N/A

What is the problem that this feature solves?

Contributors are currently recommended to keep tests for previous opsets when adding a new operator. This comes down to refactoring tests into a following fashion:

def example_test_opset13()
def example_test_opset18()

A more accurate example has been given in https://github.com/onnx/onnx/pull/4481/files#diff-104e42616962149b1dd1280f0464bc1c1a45c197934e9f21c26ba4900cfbb0eb (file split.py).

It results in a cluttered Examples section in the Operators.md file, example of which can be seen here: https://github.com/p-wysocki/onnx/blob/pwysocki/new_split18/docs/Operators.md#examples-142. In case the link is no longer available I'm also attaching a screenshot:

Only the newest version is included in the Operators.md, so it may not be the place for older opset tests. It clutters the view and forces the user to visually make sure that he/she is looking at the correct opset. The pictured section may seem small at first glance, but it will build up more and more as time goes by, for each operator.

Alternatives considered

An easy solution would be to drop the idea of keeping older opset tests, but I do not think it's appropriate.

Describe the feature

The feature could involve, for example:

• parsing the test name to see which opset it's related to and putting into docs only if it tests the newest opset,
• checking the opset_imports value for a test (https://github.com/onnx/onnx/pull/4481/files#diff-104e42616962149b1dd1280f0464bc1c1a45c197934e9f21c26ba4900cfbb0ebR76),
• adding a different directory/file to store "legacy" tests, such as it's done with old.cc.

Will this influence the current api (Y/N)?

N

Feature Area

Documentation

Are you willing to contribute it (Y/N)

Yes

Notes

No response