1.1.0 is a breaking build but wasn't marked as such

[andyfangdz]

1.1.0 was released, but it requires ruby >= 2.0.0. Previously (in 1.0.5), it was marked as >= 1.9.3.

This change is breaking for many CI systems running tests for ruby 1.9. Should we release a new minor and mark this version as bad?

[pitr-ch]

This is unfortunate, I was thinking 1.9.3 is so old that it won't be an issue for anybody (eol was 3.5 years ago). I've updated the release notes and changelog to include the change that 2.0 is required, (sorry it slipped) that I could do immediately.

Could you limit concurrent-ruby version in your Gemfile to 1.0.5 to fix your CI immediately?
Could you tell me more about your situation? Why do you still need 1.9.3? What do you mean by 'This change is breaking for many CI systems'?

The motivation behind dropping support of Ruby bellow 2.0 is to be able to start adding APIs with keywords. We cannot support 1.9.3 forever. So it's quite desirable to do.

I'd like to know more and understand better the problems this is causing before doing anything. However currently I think the 1.9.3 support drop for 1.1 was ok. I think It does not make the gem backward incompatible, although users need to meet new requirement. When ruby is >= 2.0 everything should work as before, the gem is backward compatible. Users can also stay with 1.0.5 using version restriction in Gemfile until they are able to migrate.

[andyfangdz]

Hey @pitr-ch, thanks for the response! I've limited my version to 1.0.5 to fix this issue for the mean time.

For many gems that maintain compatibility for 1.9.3, if they include a dependency on activesupport, concurrent-ruby 1.1.0 is pulled-in automatically, since there are typically no lockfiles for Gems. For CI systems that runs build for these gems, they will fail on versions of Ruby 1.9.3. These gems are often used for legacy systems that can't be rewritten but needs to be maintained.

I can certainly understand that dropping 1.9.3 support is desirable. However, the point here is that 1.1.0 is a breaking build -- it breaks for Gem authors that have gems supporting Ruby 1.9.3. Effectively, this is forcing all libraries dependent of activesupportto drop Ruby 1.9.3 as well, (or include a version constraint on concurrent-ruby, but that’s a change every library will have to make), otherwise their users' installs will fail by default. IMO, a version of 2.0.0 is more appropriate for such a change.

[pitr-ch]

Hm indeed activesupport 4.0 still supports 1.9.3, I'll yank 1.1 for now that will do no harm and think about how to approach this situation.

[jaredbeck]

Just FYI, because 1.1 was yanked we had a production deploy fail:

remote:        Fetching dependency metadata from https://rubygems.org/.
remote:        Could not find concurrent-ruby-1.1.0 in any of the sources

Easy fix, we can go back to 1.0.5, but 1.1.0 wasn't bothering us and yanking caused minor inconvenience.

[baburdick]

Same here. v1.1.0 was fine for us.

[l8nite]

Just FYI, because 1.1 was yanked we had a production deploy fail:

remote:        Fetching dependency metadata from https://rubygems.org/.
remote:        Could not find concurrent-ruby-1.1.0 in any of the sources

Easy fix, we can go back to 1.0.5, but 1.1.0 wasn't bothering us and yanking caused minor inconvenience.

Same issue here today - what a pain. :)

[tomhughes]

Broke the openstreetmap production deployment as well - bundle was updated last night and then when we deployed it today the servers could no longer install the dependencies :-(

[pitr-ch]

Sorry guys, did not realize yank can be so disruptive. Lesson learned 👍
1.1.1 should be uploaded soon.

[nijikon]

I don't see any reason why we should still support 1.9.3. People can stay on older versions if they want to run it.