Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
andyfangdz opened this issue Oct 31, 2018 · 12 comments · Fixed by #769
Closed

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

andyfangdz opened this issue Oct 31, 2018 · 12 comments · Fixed by #769
Assignees
Labels
high-priority Should be done ASAP.

Comments

@andyfangdz
Copy link

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 pitr-ch self-assigned this Oct 31, 2018
@pitr-ch pitr-ch added the high-priority Should be done ASAP. label Oct 31, 2018
@pitr-ch
Copy link
Member

pitr-ch commented Oct 31, 2018

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
Copy link
Author

andyfangdz commented Oct 31, 2018

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
Copy link
Member

pitr-ch commented Oct 31, 2018

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
Copy link

jaredbeck commented Oct 31, 2018

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
Copy link

Same here. v1.1.0 was fine for us.

@l8nite
Copy link

l8nite commented Oct 31, 2018

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
Copy link

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
Copy link
Member

pitr-ch commented Nov 1, 2018

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

@nijikon
Copy link

nijikon commented Nov 3, 2018

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.

@awkspace
Copy link

awkspace commented Nov 3, 2018

Any news on 1.1.1 being uploaded? My builds are still breaking.

@sadiqmmm
Copy link

sadiqmmm commented Nov 4, 2018

A quick solution will be to add
gem 'concurrent-ruby', '1.0.5'
to rails app Gemfile and Bundle it. It will load the concurrent-ruby version 1.0.5, not 1.1.0

@ghost ghost removed the in progress label Nov 5, 2018
@pitr-ch pitr-ch reopened this Nov 5, 2018
@pitr-ch
Copy link
Member

pitr-ch commented Nov 5, 2018

You may wish to follow #772 - which will later describe how the 1.9.3 will be dropped.
1.1.1 with 1.9.3 support was released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high-priority Should be done ASAP.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants