Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement explicit operation sunsetting #100

Open
cmars opened this issue Dec 14, 2021 · 1 comment
Open

Implement explicit operation sunsetting #100

cmars opened this issue Dec 14, 2021 · 1 comment

Comments

@cmars
Copy link
Contributor

cmars commented Dec 14, 2021

Implement the explicit operation sunsetting required by the solution proposed in #99.

Proposal here is to introduce two extensions on operations in versioned specs:

  • One that marks the operation as deprecated. This is necessary when an operation needs to be sunset without being superseded by one in a newer version.
  • One that indicates when the operation was deprecated. A linter rule (Optic CI) will need to assert that this cannot be back- or post-dated, it must match the date it lands.
cmars added a commit to cmars/vervet that referenced this issue Jan 4, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across versions of a resource.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.
cmars added a commit to cmars/vervet that referenced this issue Jan 6, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across versions of a resource.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and
resulting output. While we do not anticipate any breaking changes to
OpenAPI consumers, it's worthy of a major version bump.
cmars added a commit to cmars/vervet that referenced this issue Jan 6, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across versions of a resource.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and
resulting output. While we do not anticipate any breaking changes to
OpenAPI consumers, it's worthy of a major version bump.
cmars added a commit to cmars/vervet that referenced this issue Jan 6, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across versions of a resource.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and
resulting output. While we do not anticipate any breaking changes to
OpenAPI consumers, it's worthy of a major version bump.
cmars added a commit to cmars/vervet that referenced this issue Jan 11, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across spec versions within a stability level.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and resulting
output. It's also a breaking API change, requiring a major version bump.
We do not anticipate any breaking changes to OpenAPI consumers.
cmars added a commit to cmars/vervet that referenced this issue Jan 11, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across spec versions within a stability level.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and resulting
output. It's also a breaking API change, requiring a major version bump.
We do not anticipate any breaking changes to OpenAPI consumers.
cmars added a commit to cmars/vervet that referenced this issue Jan 11, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across spec versions within a stability level.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and resulting
output. It's also a breaking API change, requiring a major version bump.
We do not anticipate any breaking changes to OpenAPI consumers.
cmars added a commit to cmars/vervet that referenced this issue Jan 11, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across spec versions within a stability level.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and resulting
output. It's also a breaking API change, requiring a major version bump.
We do not anticipate any breaking changes to OpenAPI consumers.
cmars added a commit to cmars/vervet that referenced this issue Jan 11, 2022
Fixes snyk#99, snyk#100.

This changes how operation (path + method) are resolved and merged
across spec versions within a stability level.

Operations are now cumulative. Unless a particular operation (path +
method) is redefined or explicitly deprecated, past releases are assumed
to carry over to newer versions.

BREAKING CHANGE: This changes the behavior of the compiler and resulting
output. It's also a breaking API change, requiring a major version bump.
We do not anticipate any breaking changes to OpenAPI consumers.
@cmars
Copy link
Contributor Author

cmars commented Jan 24, 2022

I think this can be done in a single extension on the operation, x-snyk-deprecated-on, which takes a date of the form YYYY-mm-dd.

Adding x-snyk-deprecated-on to an operation should cause requests to this endpoint to be regarded as deprecated, as if it had been followed by a newer release on the date given. Sunset calculation is determined according to this date and the stability of the operation being deprecated.

A Sweater Comb rule will also be needed to prevent shenanigans, such as back-dating a deprecation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant