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

Deprecation guide #1018

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Conversation

soapy1
Copy link
Contributor

@soapy1 soapy1 commented Dec 10, 2024

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.

Copy link

netlify bot commented Dec 10, 2024

Deploy Preview for conda-store ready!

Name Link
🔨 Latest commit 9afaf5c
🔍 Latest deploy log https://app.netlify.com/sites/conda-store/deploys/677d750a601fc60008b518d2
😎 Deploy Preview https://deploy-preview-1018--conda-store.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link
Collaborator

@trallard trallard left a 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

@trallard trallard added area: documentation 📖 Improvements or additions to documentation status: needs changes 🧱 type: governance 📄 Items related to our processes and policies labels Dec 11, 2024
@soapy1 soapy1 force-pushed the deprecation-guide branch 2 times, most recently from ede5e1a to 5a120e5 Compare December 11, 2024 19:14
@soapy1 soapy1 requested a review from trallard December 16, 2024 23:10
Comment on lines 177 to 178
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.
Copy link
Collaborator

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.

Copy link
Contributor Author

@soapy1 soapy1 Dec 17, 2024

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 is 2025/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 a 410 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

Copy link
Contributor Author

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.

@soapy1 soapy1 requested a review from trallard December 17, 2024 19:23
@soapy1 soapy1 force-pushed the deprecation-guide branch from 096ecdc to b346ca0 Compare January 6, 2025 20:52
@soapy1 soapy1 requested a review from trallard January 7, 2025 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: documentation 📖 Improvements or additions to documentation needs: review 👀 type: governance 📄 Items related to our processes and policies
Projects
Status: In review 👀
Development

Successfully merging this pull request may close these issues.

3 participants