From baa7687b67484a8ef62a8bb1a6ced89c3eb330ff Mon Sep 17 00:00:00 2001 From: jaimergp Date: Sun, 26 Oct 2025 20:14:38 +0100 Subject: [PATCH 01/13] Add CFEP for package renames --- cfep-XX.md | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 cfep-XX.md diff --git a/cfep-XX.md b/cfep-XX.md new file mode 100644 index 0000000..3ce7f95 --- /dev/null +++ b/cfep-XX.md @@ -0,0 +1,44 @@ + + + + + + + + + +
Title Guidelines for renaming packages
Status Draft
Author(s) + Jaime Rodríguez-Guerra <jaime.rogue@gmail.com> +
Created Oct 26, 2025
Updated Oct 26, 2025
Discussion https://github.com/conda-forge/admin-requests/pull/1711
Implementation NA
+ +## Abstract + +This CFEP describes the principles informing how and when to rename a package in conda-forge. +Two cases are described depending on the status of the target name: + +- Unclaimed names: A package already present in conda-forge wants to use a new name currently unclaimed. +- Names in use: A package, already present or about to be submitted, wishes to use a name already in use. + +## Specification + +### Unclaimed names + +When an existing package wants to be renamed to a currently unclaimed name, the process is uncontroversial and straight-forward. Two approaches are possible: + +- The new name needs to be registered to the originating feedstock in `feedstock-outputs` (or equivalent). Once approved, a PR in the feedstock adding the new output may proceed normally. The old name is usually kept as an alias output for backwards compatibility. In this case, the feedstock retains the name of the original name. +- The original feedstock is archived and the package is re-submitted to `staged-recipes` (or equivalent) under the new name. The old package name should be added as an alias output for backwards compatibility, and registered as a valid output of the new feedstock in `feedstock-outputs`. + +### Names in use + +The blanket policy in this case is that an existing package name may not be used by a different project. In exceptional cases, the old name may be reallocated provided that: + +- The old project is either inactive or abandoned. +- There are ways to install both projects without conflicts or mixups. This includes ensuring that version numbers do not overlap and that repodata patches are applied unambiguously. When necessary, measures like marking old packages as broken or moving them to a new label may be applied. + +The original feedstock may not be reused, and must be archived. + +In case of disagreement, the core team may resolve the issue at their discretion. + +## Copyright + +All CFEPs are explicitly [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/). From 1fcdaed3e446e8e0d9d8c1c3ee2158ae29e9f079 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Wed, 29 Oct 2025 08:34:45 -0500 Subject: [PATCH 02/13] feat: add feedstock epoch labels --- cfep-XX.md | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/cfep-XX.md b/cfep-XX.md index 3ce7f95..28177c5 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -3,7 +3,7 @@ Title Guidelines for renaming packages Status Draft Author(s) - Jaime Rodríguez-Guerra <jaime.rogue@gmail.com> + Jaime Rodríguez-Guerra <jaime.rogue@gmail.com> Matthew R. Becker <becker.mr@gmail.com> Created Oct 26, 2025 Updated Oct 26, 2025 @@ -21,23 +21,38 @@ Two cases are described depending on the status of the target name: ## Specification +### Feedstock Epochs + +In order to track how feedstocks are reused, we define the concept of the `feedstock epoch` and a `feedstock epoch label`. + +- When a feedstock is first created, its epoch is 0. +- If a feedstock is reused for a new project (see below), the `feedstock epoch` MUST be incremented by 1. +- A `feedstock epoch label` is a label of the form `{feedstock name without '-feedstock'}_feedstock_epoch{N}`. When the label is applied to an artifact, the label MUST reflect epoch of the feedstock at the time it produced the given artifact. +- All artifacts uploaded from a feedstock which do not otherwise have a `feedstock epoch label` are assumed to be from the current `feedstock epoch`. +- A `feedstock epoch label` MUST be applied to any artifact from the previous epoch of the feedstock. +- The current `feedstock epoch` for a given feedstock is determined as follows. The set of all labels for all artifacts produced by the feedstock is searched for any label matching the form of a `feedstock epoch label` for that feedstock. If no label matches, then the current `feedstock epoch` is 0. If labels do match, then the current `feedstock epoch` is one plus the maximum `feedstock epoch` over all matching labels. + ### Unclaimed names When an existing package wants to be renamed to a currently unclaimed name, the process is uncontroversial and straight-forward. Two approaches are possible: -- The new name needs to be registered to the originating feedstock in `feedstock-outputs` (or equivalent). Once approved, a PR in the feedstock adding the new output may proceed normally. The old name is usually kept as an alias output for backwards compatibility. In this case, the feedstock retains the name of the original name. -- The original feedstock is archived and the package is re-submitted to `staged-recipes` (or equivalent) under the new name. The old package name should be added as an alias output for backwards compatibility, and registered as a valid output of the new feedstock in `feedstock-outputs`. +- The new name needs to be registered to the originating feedstock in `feedstock-outputs` (or equivalent). Once approved, a PR in the feedstock adding the new output may proceed normally. The old name MUST be kept as an alias output for backwards compatibility. In this case, the feedstock retains the name of the original name. +- The original feedstock is archived and the package is re-submitted to `staged-recipes` (or equivalent) under the new name. The old package name MUST be added as an alias output for backwards compatibility, and MUST be registered as a valid output of the new feedstock in `feedstock-outputs`. ### Names in use The blanket policy in this case is that an existing package name may not be used by a different project. In exceptional cases, the old name may be reallocated provided that: -- The old project is either inactive or abandoned. -- There are ways to install both projects without conflicts or mixups. This includes ensuring that version numbers do not overlap and that repodata patches are applied unambiguously. When necessary, measures like marking old packages as broken or moving them to a new label may be applied. +- The old project is abandoned. Factors that can help to indicate if a project is abandoned include, but are not limited to, the project's git repo being archived, the project's distributions no longer being available (e.g., yanked artifacts on PyPI), etc. +- There are ways to install both projects without conflicts or unintentionally installing one project versus the other. +- The version number ranges of the projects do not intersect. +- The repodata patches for the old project (if any) do not change the repodata of the new project. Adjustments to the patches for the old project can be made, but they MUST produce the same modifications to the old artifacts. +- The old project's artifacts are all marked with the `broken` label. +- The old project's artifacts are all marked with the correct `feedstock epoch label` (see above). -The original feedstock may not be reused, and must be archived. +The original feedstock MUST NOT be reused, and MUST be archived. -In case of disagreement, the core team may resolve the issue at their discretion. +The core team may resolve any ambiguities or disagreements on feedstock reuse at their sole discretion. Further, the core team reserves the right to refuse to allow a feedstock to be reused at their sole discretion. ## Copyright From 940455d4c952e9c35649f4c681c4c8dd9268de1e Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Fri, 31 Oct 2025 05:32:00 -0500 Subject: [PATCH 03/13] Update cfep-XX.md --- cfep-XX.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cfep-XX.md b/cfep-XX.md index 28177c5..71c80dd 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -21,6 +21,8 @@ Two cases are described depending on the status of the target name: ## Specification +This CFEP follows [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) in its use of certain keywords (e.g., MUST). + ### Feedstock Epochs In order to track how feedstocks are reused, we define the concept of the `feedstock epoch` and a `feedstock epoch label`. From b4c76f13187e1de4cc5fc188c9b9e0e17e849c76 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Mon, 3 Nov 2025 05:41:14 -0600 Subject: [PATCH 04/13] Update guidelines for renaming packages --- cfep-XX.md | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/cfep-XX.md b/cfep-XX.md index 71c80dd..408ce95 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -1,9 +1,9 @@ - + @@ -13,46 +13,46 @@ ## Abstract -This CFEP describes the principles informing how and when to rename a package in conda-forge. +This CFEP describes the principles informing how and when to (re)name a package in conda-forge. Two cases are described depending on the status of the target name: -- Unclaimed names: A package already present in conda-forge wants to use a new name currently unclaimed. +- Unclaimed names: A new package or a package already present in conda-forge wants to use a new name currently unclaimed. - Names in use: A package, already present or about to be submitted, wishes to use a name already in use. ## Specification This CFEP follows [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) in its use of certain keywords (e.g., MUST). -### Feedstock Epochs +### Unclaimed Names -In order to track how feedstocks are reused, we define the concept of the `feedstock epoch` and a `feedstock epoch label`. +#### New Feedstocks & Name Squatting -- When a feedstock is first created, its epoch is 0. -- If a feedstock is reused for a new project (see below), the `feedstock epoch` MUST be incremented by 1. -- A `feedstock epoch label` is a label of the form `{feedstock name without '-feedstock'}_feedstock_epoch{N}`. When the label is applied to an artifact, the label MUST reflect epoch of the feedstock at the time it produced the given artifact. -- All artifacts uploaded from a feedstock which do not otherwise have a `feedstock epoch label` are assumed to be from the current `feedstock epoch`. -- A `feedstock epoch label` MUST be applied to any artifact from the previous epoch of the feedstock. -- The current `feedstock epoch` for a given feedstock is determined as follows. The set of all labels for all artifacts produced by the feedstock is searched for any label matching the form of a `feedstock epoch label` for that feedstock. If no label matches, then the current `feedstock epoch` is 0. If labels do match, then the current `feedstock epoch` is one plus the maximum `feedstock epoch` over all matching labels. +- Unclaimed package names are typically available on a first-come-first-served basis and can be claimed by submitting a recipe for a package via `staged-recipes` (or equivalent). +- The core team reserves the right to prevent the use of certain names for any reason. Typical reasons the core team may prevent the use of a certain name include, but are not limited to, typo squating, ambiguity, violations of the code of conduct, conflicts with important infrastructure, etc. +- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via the consent of at least three core members. The core team MUST be `@`-mentioned on the relevant PR/issue and this PR/issue MUST stay open for at least one week. -### Unclaimed names +#### Renaming an Existing Package -When an existing package wants to be renamed to a currently unclaimed name, the process is uncontroversial and straight-forward. Two approaches are possible: +When an existing package wants to be renamed to a currently unclaimed name, the following steps apply: -- The new name needs to be registered to the originating feedstock in `feedstock-outputs` (or equivalent). Once approved, a PR in the feedstock adding the new output may proceed normally. The old name MUST be kept as an alias output for backwards compatibility. In this case, the feedstock retains the name of the original name. -- The original feedstock is archived and the package is re-submitted to `staged-recipes` (or equivalent) under the new name. The old package name MUST be added as an alias output for backwards compatibility, and MUST be registered as a valid output of the new feedstock in `feedstock-outputs`. +- The new name MUST be registered to the originating feedstock in `feedstock-outputs` (or equivalent). +- Once the new name is approved, a PR in the feedstock adding the new output may proceed normally. +- One of the following two options to ease the transition to the new name from the old name MUST be used. + 1. The old name is kept as an alias output on the feedstock for backwards compatibility indefinitely. + 2. The old name is kept as an alias output on the feedstock for backwards compatibility for a limited period of time. In this case, the old name MUST be marked as deprecated through the addition of a linter rule and existing feedstocks using the old name MUST be actively migrated to the new name, either by hand or through an automated service (e.g., the autotick bot). After a suitable period of time, the old name may be dropped. Packages used by many other packages SHOULD be transitioned more slowly than packages which are not used by many other packages. -### Names in use +The core team reserves the right to prevent packages from being renamed for any reason at their sole discretion. + +### Names in Use The blanket policy in this case is that an existing package name may not be used by a different project. In exceptional cases, the old name may be reallocated provided that: -- The old project is abandoned. Factors that can help to indicate if a project is abandoned include, but are not limited to, the project's git repo being archived, the project's distributions no longer being available (e.g., yanked artifacts on PyPI), etc. -- There are ways to install both projects without conflicts or unintentionally installing one project versus the other. -- The version number ranges of the projects do not intersect. +- The old project is abandoned. Factors that can help to indicate if a project is abandoned include, but are not limited to, the project's git repo being archived, the project's distributions no longer being available (e.g., yanked artifacts on PyPI), etc. For packages shipped on both conda-forge and PyPI, the package name on PyPI MUST have been inheritied by the new project from the old project. +- The two different projects can be unambiguously distinguished in the conda-forge repodata, in the sense of incompatible constraints for the package metadata (e.g., the old `foo` might only have builds that require `python <=2.7`, whereas the new `foo` would only have builds for `python >=3.10`, the version ranges do not intersect, etc.). +- The version ranges of the projects do not intersect. - The repodata patches for the old project (if any) do not change the repodata of the new project. Adjustments to the patches for the old project can be made, but they MUST produce the same modifications to the old artifacts. - The old project's artifacts are all marked with the `broken` label. -- The old project's artifacts are all marked with the correct `feedstock epoch label` (see above). - -The original feedstock MUST NOT be reused, and MUST be archived. +- The original feedstock for the old project MUST NOT be reused, and MUST be archived. The core team may resolve any ambiguities or disagreements on feedstock reuse at their sole discretion. Further, the core team reserves the right to refuse to allow a feedstock to be reused at their sole discretion. From a47396e97e35f29db457c89d0248cca80e48c9d1 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Mon, 3 Nov 2025 05:45:26 -0600 Subject: [PATCH 05/13] Update cfep-XX.md --- cfep-XX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cfep-XX.md b/cfep-XX.md index 408ce95..77c23bf 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -52,7 +52,7 @@ The blanket policy in this case is that an existing package name may not be used - The version ranges of the projects do not intersect. - The repodata patches for the old project (if any) do not change the repodata of the new project. Adjustments to the patches for the old project can be made, but they MUST produce the same modifications to the old artifacts. - The old project's artifacts are all marked with the `broken` label. -- The original feedstock for the old project MUST NOT be reused, and MUST be archived. +- The original feedstock for the old project is not reused, and instead MUST be archived. The core team may resolve any ambiguities or disagreements on feedstock reuse at their sole discretion. Further, the core team reserves the right to refuse to allow a feedstock to be reused at their sole discretion. From 2aaae4744fdf60ad99d365274ab1d898d4899268 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Tue, 4 Nov 2025 09:54:38 -0600 Subject: [PATCH 06/13] Apply suggestions from code review Co-authored-by: h-vetinari --- cfep-XX.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cfep-XX.md b/cfep-XX.md index 77c23bf..d81f4c4 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -3,7 +3,7 @@ @@ -28,8 +28,8 @@ This CFEP follows [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) in i #### New Feedstocks & Name Squatting - Unclaimed package names are typically available on a first-come-first-served basis and can be claimed by submitting a recipe for a package via `staged-recipes` (or equivalent). -- The core team reserves the right to prevent the use of certain names for any reason. Typical reasons the core team may prevent the use of a certain name include, but are not limited to, typo squating, ambiguity, violations of the code of conduct, conflicts with important infrastructure, etc. -- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via the consent of at least three core members. The core team MUST be `@`-mentioned on the relevant PR/issue and this PR/issue MUST stay open for at least one week. +- The core team reserves the right to prevent the use of certain names for any reason. Typical reasons the core team may prevent the use of a certain name include, but are not limited to, typo squatting, ambiguity, violations of the code of conduct, conflicts with important infrastructure, etc. +- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via the consent of at least three core members, and no dissent (in case of dissent, this can be solved by a vote within the core team). The core team MUST be `@`-mentioned on the relevant PR/issue and this PR/issue MUST stay open for at least one week. #### Renaming an Existing Package From 3b72c4291014cdb4db965e63bd5f5314f3861c6a Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Tue, 4 Nov 2025 09:56:02 -0600 Subject: [PATCH 07/13] Update cfep-XX.md --- cfep-XX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cfep-XX.md b/cfep-XX.md index d81f4c4..6c87223 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -29,7 +29,7 @@ This CFEP follows [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) in i - Unclaimed package names are typically available on a first-come-first-served basis and can be claimed by submitting a recipe for a package via `staged-recipes` (or equivalent). - The core team reserves the right to prevent the use of certain names for any reason. Typical reasons the core team may prevent the use of a certain name include, but are not limited to, typo squatting, ambiguity, violations of the code of conduct, conflicts with important infrastructure, etc. -- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via the consent of at least three core members, and no dissent (in case of dissent, this can be solved by a vote within the core team). The core team MUST be `@`-mentioned on the relevant PR/issue and this PR/issue MUST stay open for at least one week. +- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via the consent of at least three core members, and no dissent (in case of dissent, this can be solved by a vote within the core team). The core team MUST be `@`-mentioned on the relevant PR/issue and this PR/issue MUST stay open for at least one week. For the duration of this process (from the time core gets pinged until an answer is given), no other packages can use the names in question. #### Renaming an Existing Package From fafe24506cd800ad795dd6410c59f0bddc753285 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Tue, 4 Nov 2025 09:56:49 -0600 Subject: [PATCH 08/13] Update cfep-XX.md --- cfep-XX.md | 1 - 1 file changed, 1 deletion(-) diff --git a/cfep-XX.md b/cfep-XX.md index 6c87223..c562cb0 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -49,7 +49,6 @@ The blanket policy in this case is that an existing package name may not be used - The old project is abandoned. Factors that can help to indicate if a project is abandoned include, but are not limited to, the project's git repo being archived, the project's distributions no longer being available (e.g., yanked artifacts on PyPI), etc. For packages shipped on both conda-forge and PyPI, the package name on PyPI MUST have been inheritied by the new project from the old project. - The two different projects can be unambiguously distinguished in the conda-forge repodata, in the sense of incompatible constraints for the package metadata (e.g., the old `foo` might only have builds that require `python <=2.7`, whereas the new `foo` would only have builds for `python >=3.10`, the version ranges do not intersect, etc.). -- The version ranges of the projects do not intersect. - The repodata patches for the old project (if any) do not change the repodata of the new project. Adjustments to the patches for the old project can be made, but they MUST produce the same modifications to the old artifacts. - The old project's artifacts are all marked with the `broken` label. - The original feedstock for the old project is not reused, and instead MUST be archived. From 705ba8491ccf0cc9b632a8b9b6789bc111421c05 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Mon, 10 Nov 2025 05:22:13 -0600 Subject: [PATCH 09/13] Update cfep-XX.md --- cfep-XX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cfep-XX.md b/cfep-XX.md index c562cb0..0f35a4e 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -28,7 +28,7 @@ This CFEP follows [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) in i #### New Feedstocks & Name Squatting - Unclaimed package names are typically available on a first-come-first-served basis and can be claimed by submitting a recipe for a package via `staged-recipes` (or equivalent). -- The core team reserves the right to prevent the use of certain names for any reason. Typical reasons the core team may prevent the use of a certain name include, but are not limited to, typo squatting, ambiguity, violations of the code of conduct, conflicts with important infrastructure, etc. +- The core team reserves the right to prevent the use of any package name for any reason. Typical reasons the core team may prevent the use of a package name include, but are not limited to, typo squatting, ambiguity, violations of the code of conduct, conflicts with important infrastructure, name conflicts with recipes in the `bioconda` channel, etc. - Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via the consent of at least three core members, and no dissent (in case of dissent, this can be solved by a vote within the core team). The core team MUST be `@`-mentioned on the relevant PR/issue and this PR/issue MUST stay open for at least one week. For the duration of this process (from the time core gets pinged until an answer is given), no other packages can use the names in question. #### Renaming an Existing Package From de127f9c3e28aa76c76b5a45e56a8eec4410f962 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Tue, 11 Nov 2025 15:59:59 -0600 Subject: [PATCH 10/13] Update cfep-XX.md --- cfep-XX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cfep-XX.md b/cfep-XX.md index 0f35a4e..2c15d32 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -29,7 +29,7 @@ This CFEP follows [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) in i - Unclaimed package names are typically available on a first-come-first-served basis and can be claimed by submitting a recipe for a package via `staged-recipes` (or equivalent). - The core team reserves the right to prevent the use of any package name for any reason. Typical reasons the core team may prevent the use of a package name include, but are not limited to, typo squatting, ambiguity, violations of the code of conduct, conflicts with important infrastructure, name conflicts with recipes in the `bioconda` channel, etc. -- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via the consent of at least three core members, and no dissent (in case of dissent, this can be solved by a vote within the core team). The core team MUST be `@`-mentioned on the relevant PR/issue and this PR/issue MUST stay open for at least one week. For the duration of this process (from the time core gets pinged until an answer is given), no other packages can use the names in question. +- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via a vote or some other procedure decided at their discretion. #### Renaming an Existing Package From f229a2b6ae695278ba229b368726bb46b1c88605 Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Thu, 13 Nov 2025 06:51:25 -0600 Subject: [PATCH 11/13] Apply suggestion from @beckermr --- cfep-XX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cfep-XX.md b/cfep-XX.md index 2c15d32..64fd7bd 100644 --- a/cfep-XX.md +++ b/cfep-XX.md @@ -29,7 +29,7 @@ This CFEP follows [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) in i - Unclaimed package names are typically available on a first-come-first-served basis and can be claimed by submitting a recipe for a package via `staged-recipes` (or equivalent). - The core team reserves the right to prevent the use of any package name for any reason. Typical reasons the core team may prevent the use of a package name include, but are not limited to, typo squatting, ambiguity, violations of the code of conduct, conflicts with important infrastructure, name conflicts with recipes in the `bioconda` channel, etc. -- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless expressly approved by the core team via a vote or some other procedure decided at their discretion. +- Pre-registering or squatting on a namespace in anticipation of future use is not allowed unless approved by the core team. #### Renaming an Existing Package From d703c71c2935a4e747978ff0dbe1c1e5222cbf9c Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Fri, 6 Feb 2026 11:34:55 -0600 Subject: [PATCH 12/13] Update status and last updated date in cfep-26.md --- cfep-XX.md => cfep-26.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename cfep-XX.md => cfep-26.md (97%) diff --git a/cfep-XX.md b/cfep-26.md similarity index 97% rename from cfep-XX.md rename to cfep-26.md index 64fd7bd..a1f0cf2 100644 --- a/cfep-XX.md +++ b/cfep-26.md @@ -1,12 +1,12 @@
Title Guidelines for renaming packages
Title Guidelines for (Re)Naming Packages
Status Draft
Author(s) - Jaime Rodríguez-Guerra <jaime.rogue@gmail.com> Matthew R. Becker <becker.mr@gmail.com> + Jaime Rodríguez-Guerra <jaime.rogue@gmail.com>, Matthew R. Becker <becker.mr@gmail.com>
Created Oct 26, 2025
Updated Oct 26, 2025
Title Guidelines for (Re)Naming Packages
Status Draft
Author(s) - Jaime Rodríguez-Guerra <jaime.rogue@gmail.com>, Matthew R. Becker <becker.mr@gmail.com> + Jaime Rodríguez-Guerra <jaime.rogue@gmail.com>, Matthew R. Becker <becker.mr@gmail.com>, Axel Obermeier <h.vetinari@gmx.com>
Created Oct 26, 2025
Updated Oct 26, 2025
- + - +
Title Guidelines for (Re)Naming Packages
Status Draft
Status Accepted
Author(s) Jaime Rodríguez-Guerra <jaime.rogue@gmail.com>, Matthew R. Becker <becker.mr@gmail.com>, Axel Obermeier <h.vetinari@gmx.com>
Created Oct 26, 2025
Updated Oct 26, 2025
Updated Feb, 6, 2026
Discussion https://github.com/conda-forge/admin-requests/pull/1711
Implementation NA
From acfcf9c8a7489b1a176ca8ab67a3a5109b8c7f2b Mon Sep 17 00:00:00 2001 From: "Matthew R. Becker" Date: Fri, 6 Feb 2026 11:35:43 -0600 Subject: [PATCH 13/13] Add CFEP-26 guidelines for (Re)Naming Packages --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index aea8ef2..93a2658 100644 --- a/README.md +++ b/README.md @@ -34,3 +34,4 @@ is given in CFEP-00. | [CFEP-23](cfep-23.md) | Migration to the Zulip chat platform | | [CFEP-24](cfep-24.md) | More Secure Package Name Approval Process | | [CFEP-25](cfep-25.md) | Globally Pinned Minimum Python Version for `noarch: python` Packages | +| [CFEP-26](cfep-26.md) | Guidelines for (Re)Naming Packages |