Update CHANGELOG to mention pulled 2.5.0.4 version

[swrobel]

Not sure why it was pulled, but it's probably worth mentioning...

[whitequark]

The changelog is automatically generated.

I've pulled the version because, due to a merge screwup, it didn't match the tag.

[perlun]

@whitequark

I've pulled the version because, due to a merge screwup, it didn't match the tag.

While I appreciate your contributions to the community, please do not pull back published versions. It's one of the most frustrating things you can do as an open source maintainer, since it causes a lot of churn to everybody who has to bump their dependency list. 😢

If you make a mistake and release a bad version, the right thing to do in 99% of the cases is to not yank the bad version (we all make mistakes, that's not the point here), but to:

• Publish an updated version which has the correct content
• Add a note to the repo/changelog etc saying "do not use version x, it is broken"

Yanking is almost always wrong, unless you really messed up and published confidential information, code that contains a virus etc.

[whitequark]

Oh, I had no idea yank was changed to permanently delete the gem back in 2015. That's an awful decision, if you publish credentials you should just change them, not rely on there being no one scraping all uploaded gems...

[iliabylich]

Maybe it makes sense to push it back. Is it possible?

[perlun]

Oh, I had no idea yank was changed to permanently delete the gem back in 2015. That's an awful decision

Hmm, agree. Didn't know that they actually changed that a few years ago. I think the NuGet approach is "the right thing". Yank should be "remove from public lists & search results, but not remove from direct URLs" (https://docs.microsoft.com/en-us/nuget/policies/deleting-packages)

As @iliabylich suggests, maybe it would make sense to re-publish the package (be it with 2.5.0.5 content or whatever) to minimize the community damage. Thanks for very fast feedback!

[nunosilva800]

CI's.... CI's breaking everywhere :(

Your bundle is locked to parser (2.5.0.4), but that version could not be found
in any of the sources listed in your Gemfile. If you haven't changed sources,
that means the author of parser (2.5.0.4) has removed it. You'll need to update
your bundle to a different version of parser (2.5.0.4) that hasn't been removed
in order to install.

[whitequark]

It's not possible to push over a yanked gem version so there's nothing I can do about it beyond unyanking (which is even worse). Complain to rubygems.org, I guess.

[perlun]

@whitequark

Complain to rubygems.org, I guess.

Please do. I think their current policy is completely broken. It should be extremely hard to yank a package, if it happens more than 5 minutes after it was pushed.

[whitequark]

Please do. I think their current policy is completely broken. It should be extremely hard to yank a package, if it happens more than 5 minutes after it was pushed.

Note that, if I remember correctly, I've pulled the package within 5 minutes. At a certain volume of installations it just doesn't matter. Yanking must not remove the actual file.

But it seems unlikely to me that this policy change will be reverted, and in any case I don't really participate in the Ruby ecosystem anymore.

[Temikus]

Got here because my Lockfile contained a version that no longer existed. It's no biggie, just got curious what happened.

For posterity sake I'll add this to others that are curious - AFAIK official policy of RubyGems is that repushing of gem versions is not allowed to prevent unexpected behavior that they're not staffed to deal with (cached versions, webhooks).

A bit more info on it here: https://blog.rubygems.org/2015/04/13/permadelete-on-yank.html

[perlun]

For posterity sake I'll add this to others that are curious - AFAIK official policy of RubyGems is that repushing of gem versions is not allowed to prevent unexpected behavior that they're not staffed to deal with (cached versions, webhooks).

Good point. Anyway, we should push them to change the policy so that yanking doesn't remove the actual file, but only makes it "undiscoverable".

Since they have had their current semantics for 3 years now, I think they are unlikely to want to change it, but they are still wrong. 😜