Yank/Unpublish 2.2.3

[adhami3310]

As that package version is unusable, it must be yanked as soon as possible. A separate hotfix should be done but only after the package is back at a working stage. Even if the hotfix is merged, an unworking version must always be yanked.

[rolandjitsu]

It doesn't really make sense to me to do that since semver ranges such as ^1.2.3 or ~1.2.3, dictates to use the latest patch, which is what could be causing issues. Unless you specifically pin down to the broken version, package managers should pick up the latest patch.

For now, I'll keep the versions as are unless the patch doesn't get published.

According to https://github.com/react-dropzone/attr-accept/actions/runs/11261768587/job/31315936062, the 2.2.4 versions should have been published, but I cannot see it yet on npmjs.com (though I can install it locally).

[adhami3310]

Let's listen to crates.io as NPM doesn't speak on the issue:

Crates should only be yanked in exceptional circumstances, for example, an accidental publish, an unintentional SemVer breakages, or a significantly broken and unusable crate.

I believe "significantly broken and unusable" is grounds for unpublishing this version.

[rolandjitsu]

If you can reproduce a use case in which leaving as is causes an issue (without installing 2.2.3 specifically), I'd be more than happy to unpublish.

…

On Wed, Oct 9, 2024, 22:44 Khaleel Al-Adhami ***@***.***> wrote: Let's listen to crates.io as NPM doesn't speak on the issue: Crates should only be yanked in exceptional circumstances, for example, an accidental publish, an unintentional SemVer breakages, or a significantly broken and unusable crate. I believe "significantly broken and unusable" is grounds for unpublishing this version. — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALJIOMR4E3SUDKEDGVW3ELZ2WBQNAVCNFSM6AAAAABPVHXVROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTGI4TSOBVHA> . You are receiving this because you commented.Message ID: ***@***.***>

[Alek99]

I don't quite understand this logic of having downstream users prove an unusable release is a problem, when it can be simply removed. Mistakes happen that's why unpublish commands exists. If the version has no functional utility and doesn't run why keep it, is it to just maintain continuity in versioning?

It's your library so you can do whatever you want at the end of the day. It's just not good practice imo as a library with many down stream dependents.

[rolandjitsu]

The reasoning is simple: we let the semver take care of the issue. There's a patch that should take care of the issue. If there are further issues, we'll look into it. Removing a previous version has no value at this point unless it really is causing issue.

…

On Thu, Oct 10, 2024, 08:45 Alek Petuskey ***@***.***> wrote: I don't quite understand this logic of having downstream users prove an unusable release is a problem, when it can be simply removed. Mistakes happen that's why unpublish commands exists. If the version has no functional utility and doesn't run why keep it, is it to just maintain continuity in versioning? It's your library so you can do whatever you want at the end of the day. It's just not good practice imo as a library with many down stream dependents. — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALJIOLSR3PFMY5IQS3OVHLZ2YH6LAVCNFSM6AAAAABPVHXVROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBUGA4DEMJZGM> . You are receiving this because you commented.Message ID: ***@***.***>