You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a library maintainer requests the removal of a release from Library Manager, reject any new releases that have the same version number.
🙂 This will avoid confusion to Library Manager users caused by ambiguity in versioning that would otherwise result from there having been two different releases registered under the same version number over time.
🙂 This is essential to guarantee reproducible project builds.
Describe the current behavior
The sole identifier for a library release is the version number.
We allow library maintainers to request the removal of a release. This is intended to only be used in rare emergency cases where a release contains content that absolutely must not be distributed (e.g., a copyright violation).
Currently, when a release is removed, the "DB" entry for the release is removed entirely.
🙁 If the library maintainer later makes a new release with the same version number, it could cause confusion for users of the library, since they might have either revision of the library depending on whether they installed it before or after the remove+re-release sequence.
🙁 The ability to re-release encourages the abuse of release removal requests by library maintainers for non-emergency cases where they simply want a "do-over" on a fumbled release instead of taking the responsible approach of making a new release to correct the problem with the previous release (e.g., arduino/library-registry#1449, arduino/library-registry#4618).
This would be implemented by changing the remove command to mark a release as "removed" in the "DB" instead of removing the entry as it does now.
The index generation code would be configured to skip over these releases.
The npm package registry uses the same approach to handling release removals:
Describe the request
After a library maintainer requests the removal of a release from Library Manager, reject any new releases that have the same version number.
🙂 This will avoid confusion to Library Manager users caused by ambiguity in versioning that would otherwise result from there having been two different releases registered under the same version number over time.
🙂 This is essential to guarantee reproducible project builds.
Describe the current behavior
The sole identifier for a library release is the version number.
We allow library maintainers to request the removal of a release. This is intended to only be used in rare emergency cases where a release contains content that absolutely must not be distributed (e.g., a copyright violation).
Currently, when a release is removed, the "DB" entry for the release is removed entirely.
🙁 If the library maintainer later makes a new release with the same version number, it could cause confusion for users of the library, since they might have either revision of the library depending on whether they installed it before or after the remove+re-release sequence.
🙁 The ability to re-release encourages the abuse of release removal requests by library maintainers for non-emergency cases where they simply want a "do-over" on a fumbled release instead of taking the responsible approach of making a new release to correct the problem with the previous release (e.g., arduino/library-registry#1449, arduino/library-registry#4618).
libraries-repository-engine version
011349f
Additional context
This would be implemented by changing the
remove
command to mark a release as "removed" in the "DB" instead of removing the entry as it does now.The index generation code would be configured to skip over these releases.
The npm package registry uses the same approach to handling release removals:
https://docs.npmjs.com/policies/unpublish#considerations
Related
Issue checklist
The text was updated successfully, but these errors were encountered: