search

conda / ceps

Conda Enhancement Proposals
Creative Commons Zero v1.0 Universal
19 stars 24 forks source link

CEP 9: Conda Deprecation Schedule #27

Closed kenodegard closed 1 year ago

kenodegard commented 2 years ago

As we seek to remove outdated code and bring conda and conda-build back into the modern Python era (#24) it's more important to define a clear deprecation policy such that downstream applications are properly notified of pending deprecations.

This proposed deprecation policy hinges on ideas from #26 so much of this could be reworked pending modifications made there.

jezdez commented 1 year ago

@conda-incubator/steering

This pull request falls under the Enhancement Proposal Approval policy of the conda governance policy, please vote and/or comment on this PR.

It needs 60% of the Steering Council to vote yes to pass.

To vote, please leave a regular pull request review (see Files changed tab above > green Review changes button) with one of the following options:

Also, if you would like to suggest changes to the current proposal, please leave a comment below, use the regular review comments or push to this branch.

This vote will end on 2022-10-07.

kenodegard commented 1 year ago

@beckermr Hm, no, we haven't decided on how we decide on what gets deprecated. This CEP is a response to the realization that as we tackle tech debt, we keep finding functionality that is outdated/unused or has long since been replaced. This is intended to be more of a warning system for downstream projects and to inform them of the correct alternative.

Yes, we should view the pending deprecation as a comment period. It wouldn't hurt to outline a process for disputing a deprecation, I'll put something together.

kenodegard commented 1 year ago

~No, we are not zero padding months in CEP8~

Ah I misread, yes every year there will be at least YY.11.0 per CEP8

kenodegard commented 1 year ago

@beckermr just added details on:

Let me know if you have additional concerns

beckermr commented 1 year ago

Thank you. That looks great! If we create a technical group sometime in the future we should appeal decisions to them.

dholth commented 1 year ago

We could probably get away with using DeprecationWarning only (since Python's PendingDeprecationWarning is a bit deprecated itself) and use comments / deprecation tooling to note exactly how deprecated something was.

jezdez commented 1 year ago

We could probably get away with using DeprecationWarning only (since Python's PendingDeprecationWarning is a bit deprecated itself) and use comments / deprecation tooling to note exactly how deprecated something was.

Regarding PendingDeprecationWarning, do you mean https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038?

A conda.warnings.deprecated() function or similar to what @brettcannon has suggested in the the thread for CPython would greatly simplify enforcing of this CEP.

jezdez commented 1 year ago

Voting Results

This was a standard, non-timed-out vote.

Among Steering Council members there are 10 "yes", 0 "no", and no abstentions.

This vote has reached quorum (10 is at least 60% of 16).

It has also passed since it recorded 10 "yes" votes and 0 "no" votes giving 10/10 which is greater than 60% of 16.

It should be noted that a request for change was recorded in the pull request about minor implementation details that do not invalidate the previous votes. The author made the requested change.

brettcannon commented 1 year ago

@jezdez it's gone passed a suggestion 😁

https://github.com/python/cpython/blob/b863b9cd4b8681cf5fff5f121837a1039045783f/Lib/warnings.py#L498-L514