-
Notifications
You must be signed in to change notification settings - Fork 52
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
Deprecation guide #1018
base: main
Are you sure you want to change the base?
Deprecation guide #1018
Conversation
✅ Deploy Preview for conda-store ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
13f710d
to
f98f1a1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @soapy1, though this overlaps with our existing policies so added a few comments that will need to be adressed
ede5e1a
to
5a120e5
Compare
5a120e5
to
7bdc92a
Compare
the endpoint. It will be specified as a [HTTP-Date](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date). The removal date can be set to (at earliest) the date of the target | ||
next release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above:
The removal date can be set to (at earliest) the date of the target
next release.
Since we use CalVer and do not have set release dates, this puts us in a position where we need to agree on a release and meet it no matter what.
Since we do not have a set release schedule, this is rather ambiguous, so we need a clearer guideline here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can be more specific here.
I think sunset date should be set to about 2 months from the release that the deprecation is going out in.
- Any time before this date, users should expect this endpoint to work
- Any time after this date, the endpoint may still be available (due to no release having gone out), but users should expect that this endpoint will disappear
For example, say you have an endpoint /hello-planet
that is getting deprecated. The whole removal cycle will be something like:
- 2024/12/17 - add deprecation headers to
/hello-planet
, sunset date is2025/03/17
- 2024/12/19 - new release goes out (sunset date is more than 2 months away, so everything is good)
- 2025/01/30 - new release goes out,
/hello-planet
is still deprecated - 2025/03/16 - new emergency release goes out to fix a discovered security vulnerability. Still before the
/hello-planet
sunset date, so it remains in the deprecated state - 2025/03/17 -
/hello-planet
sunset date. No release so this endpoint is still functional, however will be yanked at next release - 2025/03/29 - new release goes out
/hello-planet
endpoint functionality is removed, returns a410
response with removal date (eg. 2025/04/29) - 2025/04/29 - new release goes out. Happens to coincide with the removal date. Can remove the endpoint as part of this release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the removal of functionality step offers much more help to users than the deprecation step. If the team is open to changing this more, I would advocate for jumping straight from deprecating the endpoint to removing the endpoint after the sunset date.
890571a
to
a5841b4
Compare
Co-authored-by: Tania Allard <[email protected]>
096ecdc
to
b346ca0
Compare
Description
This PR adds some docs around how conda-store is handling deprecations. It also adds a
Sunset
header to deprecated api endpoints to denote when they will be removed.