Why are the rubygems releases being removed?

[lfv89]

Second time in the past couple months... These removals keep breaking our build.

Any thoughts? Thanks.

[tagliala]

Hi,

Unfortunately 5.5.1 and 5.5.2 contain unintended breaking changes #181 and they should not be used

I've yanked the affected versions only after the release of the hotfix.

If this is causing more issues, I will stop doing that and just release the hotfix

Hope it helps

Closing here

[lfv89]

👍

[tagliala]

@lfv89 I've read somewhere to yank. I thought it was written in the semver specs themselves, but I was wrong.

Anyway, maybe I read a blog post in the past with something like this:

https://github.com/sferik/twitter#versioning

Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, that version should be immediately yanked and/or a new version should be immediately released that restores compatibility.

I'm doing both at the moment.

What approach do you think it is best? A broken build (symptom of a potential breaking change) or a new hotfix thath you could miss in your build?

[enriclluelles]

I'd prefer very much not yanking. For many reasons, but mainly it breaks code/applications that are running fine until now(maybe the bug doesn't affect them, maybe they use only part of the lib). There are better, non-intrusive ways to get notified that you need to bump the minor or patch version of a dependency that having a broken build. You could also have a deployment process that performs a `bundle install` of the gem when deploying an instance of the app(even though it's brittle) That would also impair said process when, say, scaling up the number of instances. Flexible versioning schemes with like `5.2.x` or `~> 5.2.1` exist for this reason, along with lock files

…

On 12 Jan 2018, at 14:31, Geremia Taglialatela ***@***.***> wrote: @lfv89 I've read somewhere to yank. I thought it was written in the semver specs themselves, but I was wrong. Anyway, maybe I read a blog post in the past with something like this: https://github.com/sferik/twitter#versioning Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, that version should be immediately yanked and/or a new version should be immediately released that restores compatibility. I'm doing both at the moment. What approach do you think it is best? A broken build (symptom of a potential breaking change) or a new hotfix thath you could miss in your build? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tagliala]

@enriclluelles thanks for the clarification, now I can completely understand the issue of yanking gems

I will just release the hotfix when an unintended breaking change occurrs 👍

[lfv89]

Thanks for the fast reply guys. I'm totally on board with the solution given.