Add optional field to the Operation object to indicate initial version containing the implementation

[JamesMGreene]

I would love to add a version-related field to the Operation object (so per HTTP method of an Endpoint) that indicates the first version of the API that shipped with this functionality implemented.

For instance, the current API version is 18.0.0 but operation "GET /api/v1/jobs" was first shipped in version 17.1.0.

Nice to know for backward compatibility.

Also nice for developers to keep track of what versions offer what features. 😜

[DavidBiesack]

We've been planning to use an x- vendor extension for this, x-sas-since. We can also use this in schema and schema members to note when a member was added. A standard way to do this would be nice, or at least a standard vendor extension namespace such as x-openapi-since.

[LasneF]

notice the @since concept is common in the documentation space

for instance @since is part of Javadoc https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#since

in the context of OAS could apply to nearly any data point , path , parameter , option, fields

on javascript leveraging JSDoc https://jsdoc.app/tags-since

it can be usefull when as a software editor to know if an client application developped against a server 1.2.0 may work against a server on 1.1.0 . because using only feature that is part of 1.1.0

as well if you are client developper to maximize the potential compatibility surface