Loomio

Ruby versions

JH
Jonne Haß Public Seen by 214

Discussion on what Ruby versions to support, recommend and migrate to.

JH

Jonne Haß started a proposal Thu 19 Dec 2013

Bump recommended Ruby version to 2.0.0 before the next release Closed Fri 20 Dec 2013

Outcome
by Jonne Haß Tue 25 Apr 2017

We're going to bump the recommend Ruby version

Results
Agree - 11
Abstain - 11
Disagree - 11
Block - 11
11 people have voted (19%)
JH

Jonne Haß Thu 19 Dec 2013

Upcoming proposals:

  • Drop support for Ruby 1.9.3
  • Run Travis builds for both, Ruby 1.9.3 and 2.0.0
JH

Jonne Haß
Agree
Thu 19 Dec 2013

F

Flaburgan
Agree
Thu 19 Dec 2013

F

fabianrbz
Agree
Thu 19 Dec 2013

supporting 1.9.3 in travis is fine by me, but I think we should remove that in the release after this one

DS

Dennis Schubert
Abstain
Thu 19 Dec 2013

I'd totally vote against it in favour of a easy ruby installation via the systems package manager.

But as 2.0 has sooo many improvements, I'd be fine with dropping 1.9.*.

ST

Sean Tilley
Agree
Thu 19 Dec 2013

ST

Sean Tilley Thu 19 Dec 2013

Hmm...DenSchub makes a good point though.

EG

Erwan Guyader
Agree
Thu 19 Dec 2013

ST

Sean Tilley
Agree
Thu 19 Dec 2013

MM

Marek Marecki
Agree
Thu 19 Dec 2013

JH

Jonne Haß Thu 19 Dec 2013

@dennisschubert this is about supporting 2.0.0 and doing it in the next release. Dropping support for 1.9.3 will be the next proposal.

DS

Dennis Schubert
Agree
Thu 19 Dec 2013

MS

maxwell salzberg
Agree
Thu 19 Dec 2013

DS

Dennis Schubert Thu 19 Dec 2013

@jonnehass crap. excuse me.

C

Carolina
Agree
Thu 19 Dec 2013

SVB

Steffen van Bergerem
Agree
Fri 20 Dec 2013

R

Ruxton
Agree
Fri 20 Dec 2013

JH

Jonne Haß Fri 20 Dec 2013

Okay, I think that's clear already. Lets move to the more controversial stuff.

JH

Jonne Haß started a proposal Fri 20 Dec 2013

Drop support for Ruby 1.9.3 Closed Mon 23 Dec 2013

Outcome
by Jonne Haß Tue 25 Apr 2017

We keep support for Ruby 1.9.3 - at least for a while.

Results
Agree - 1
Abstain - 1
Disagree - 1
Block - 1
8 people have voted (15%)
JH

Jonne Haß
Disagree
Fri 20 Dec 2013

Given the history of Ruby support in various distributions, I think we should support Ruby 1.9.3 at least until its official maintenance is phased out or the major distributions have Ruby 2 available in their repositories.

DS

Dennis Schubert
Disagree
Fri 20 Dec 2013

I'd totally vote against it in favour of a easy ruby installation via the systems package manager. But as 2.0 has sooo many improvements, I'd be fine with dropping 1.9.*.

G

goob Fri 20 Dec 2013

What (if any) advantages would there be to dropping support for 1.9.3?

F

Flaburgan Fri 20 Dec 2013

@goob well the problem can be that we want to upgrade Sidekiq, and the Sidekiq team strongly recommand to upgrade to Ruby 2.0 first. So if we still support Ruby 1.9.3, we will have podmins with an old Ruby but the new sidekiq, and we don't know what will be going on...

F

Flaburgan
Abstain
Fri 20 Dec 2013

In one hand, I don't want diaspora* to be harder to install, in the other hand, if we want to upgrade sidekiq, we kind of have to upgrade to Ruby 2.0. Soooo...

JH

Jonne Haß Fri 20 Dec 2013

@goob increased maintenance cost and build times on Travis (if we decide to not drop it here and to run it on travis in the next proposal I'll open).

G

goob Fri 20 Dec 2013

OK thanks, both of you.

G

goob
Disagree
Fri 20 Dec 2013

In an ideal world, I'd like to retain support for previous versions; however if it starts to consume unnecessary resources, I'm happy for it to be dropped.

My vote is almost an abstain: I'm happy for the core team to decide when to drop it.

JR

Jason Robinson
Abstain
Fri 20 Dec 2013

Happy for the real Ruby knowhow people to decide :)

EG

Erwan Guyader
Abstain
Fri 20 Dec 2013

G

goob
Abstain
Fri 20 Dec 2013

In an ideal world, I'd like to retain support for previous versions; however if it starts to consume unnecessary resources, I'm happy for it to be dropped.

I'm happy for those who understand Ruby to decide when to drop support for 1.9.3.

F

fabianrbz
Agree
Fri 20 Dec 2013

alright, I don't mind supporting 1.9.3 for a while

JR

Jason Robinson Sat 21 Dec 2013

@fabianrbz if you want to support 1.9.3 I think you should disagree, not agree? ;)

F

fabianrbz Sat 21 Dec 2013

@jasonrobinson, actually I don't, but I'm ok with supporting it for a while

FS

Florian Staudacher
Disagree
Mon 23 Dec 2013

ideally, we should drop 1.9.3 support, but I think we should at least keep it until we have a few more distros with 2.0 packages

JH

Jonne Haß started a proposal Sun 29 Dec 2013

Run builds for Ruby 1.9.3 on Travis Closed Thu 2 Jan 2014

Outcome
by Jonne Haß Tue 25 Apr 2017

We keep running builds for Ruby 1.9.3 on Travis

Since we still want to support Ruby 1.9.3, we also shold invest the time on Travis for running builds on it.

Results
Agree - 2
Abstain - 2
Disagree - 2
Block - 2
7 people have voted (13%)
JH

Jonne Haß
Abstain
Sun 29 Dec 2013

The differences between 2.0.0 and 1.9.3 aren't that big, though on the other hand we might not notice if we break backwards compatibility.

JR

Jason Robinson Sun 29 Dec 2013

Hmm so we would run a separate build for 1.9.3? What does this mean in practice? Longer test runs I assume?

F

Flaburgan
Agree
Sun 29 Dec 2013

If we support it, it's kind of obvious we need to test it. We will remove it from travis the same time we will stop supporting it.

G

goob
Abstain
Sun 29 Dec 2013

Totally happy for the experts to decide. It sounds better to continue testing, but if there are serious performance implications, might have to drop it.

TS

Tom Scott
Agree
Mon 30 Dec 2013

F

fabianrbz
Disagree
Mon 30 Dec 2013

the differences aren't that big and the cost of running our test suite in 1.9.3 and 2.0 are too high in my opinion... I know we want to have backward compatibility, but I think if something breaks we will know it via github...

JR

Jason Robinson Mon 30 Dec 2013

Anyone want to give light into the actual how running both will reflect the test running? :)

DS

Dennis Schubert
Abstain
Wed 1 Jan 2014

I'd totally vote against it in favour of a easy ruby installation via the systems package manager. But as 2.0 has sooo many improvements, I'd be fine with dropping 1.9.*.

FS

Florian Staudacher
Abstain
Thu 2 Jan 2014

no strong feelings either way ... yes, we should keep CI for a version we continue to support, but yes, we should also try not to overstress Travis' resources we're gladly using for free

JH

Jonne Haß Thu 2 Jan 2014

@dennisschubert it's reading the proposal time again ;)

TS

Tom Scott
Agree
Thu 2 Jan 2014

i know it's going to make our test suite run twice as long but imho that's a small price to pay for avoiding regression. until we can prove without ANY doubt that it is a waste of time, we shouldn't remove it.

DS

Dennis Schubert Fri 3 Jan 2014

@jonnehass actually, no. while the text is a bit edgy in this case, the argument is still totally valid. ;)

JH

Jonne Haß started a proposal Sun 24 Aug 2014

Drop Ruby 1.9 support, adopt Ruby 2.1 support Closed Sat 30 Aug 2014

Outcome
by Jonne Haß Tue 25 Apr 2017

The proposal was accepted.

Ruby 2.2 is on the door, major Ruby libraries start to drop support for Ruby 1.9. Let's make maintenance easier and drop Ruby 1.9 support and move forward to Ruby 2.1.

Support for Ruby 2.0 will be kept for now.

What changed?

Ubuntu has Ruby 2.0 since Saucy.
Debian will have Ruby 2.1 in Jessie.
Fedora has Ruby 2.0 since 19.
CentOS has Ruby 2.0 since 7.

Results
Agree - 10
Abstain - 10
Disagree - 10
Block - 10
10 people have voted (18%)
JH

Jonne Haß
Agree
Sun 24 Aug 2014

SVB

Steffen van Bergerem
Agree
Sun 24 Aug 2014

DS

Dennis Schubert
Agree
Sun 24 Aug 2014

EG

Erwan Guyader
Agree
Sun 24 Aug 2014

F

Flaburgan
Agree
Sun 24 Aug 2014

FS

Florian Staudacher
Agree
Sun 24 Aug 2014

FS

Florian Staudacher Sun 24 Aug 2014

... will also decrease our travis build time somewhat

G

goob
Agree
Mon 25 Aug 2014

It looks as though now is a good time to do this.

F

Flaburgan Mon 25 Aug 2014

@florianstaudacher well if we introduce 2.1 instead of 1.9, this is unlikely, isn't it?

JH

Jonne Haß Mon 25 Aug 2014

2.1 is faster than 1.9 and 2.0. Compare build times between 2.0 and 1.9 on Travis.

JR

Jason Robinson Wed 27 Aug 2014

If they keep erroring we should just bite it and drop 2.0 once we move to 2.1 - imho.

JR

Jason Robinson
Agree
Wed 27 Aug 2014

DU

[deactivated account]
Agree
Wed 27 Aug 2014

ST

Sean Tilley
Agree
Wed 27 Aug 2014

Do it!

JR

Jason Robinson started a proposal Fri 7 Nov 2014

Drop previous Ruby from the Travis builds Closed Sat 8 Nov 2014

Outcome
by Jason Robinson Tue 25 Apr 2017

Closed proposal early with no result

Unfortunately Travis builds are way too often still ending up in error. Our builds, doing both 2.1 and 2.0 for all tests, take up to or more than 4 hours - and at that time Travis kills the switch.

I'm under the feeling we're not only getting bad automatic testing by trying to build too much, but also abusing the free service from the Travis guys.

My proposal is to stop building for 2.0 in development, since there the recommended version is 2.1. The .travis.yml ruby versions should match the ruby version of .ruby-version - and only that.

Vote;

  • YES - agree to build only for current recommended ruby version (per branch built)
  • NO - keep as is, eg build for two ruby versions

Results
Agree - 1
Abstain - 1
Disagree - 1
Block - 1
3 people have voted (5%)
JR

Jason Robinson
Agree
Fri 7 Nov 2014

F

Faldrian
Agree
Fri 7 Nov 2014

Less trouble in restarting failed validation. Also nicer for the travis guys.

JH

Jonne Haß
Abstain
Fri 7 Nov 2014

I would prefer CI for all supported versions. Afaik the limitation is 50 minutes per job, not 4 hours per build. And Travis is a well established company by now, we're not abusing anything. Though I won't oppose shorter build times.

JR

Jason Robinson Fri 7 Nov 2014

Ah! Should have looked around a bit - indeed it is 50 minutes per build.

So dropping rubies will not stop errors completely, though it might make them less frequent.

I guess the real solution would be to break the test suites into smaller parts?

F

Faldrian
Abstain
Fri 7 Nov 2014

I would like less timeouts / build errors, but I can't say if this will help.

JH

Jonne Haß Sat 8 Nov 2014

The real solution is to make our testsuite faster. For the cucumber that means looking into converting some cukes to jasmine/rspec tests, looking into if we can speedup database_cleaner which runs after every scenario and looking into whether alternate capybara drivers like poltergeist would speed things up. For rspec this means looking into creating less objects in the database where possible (using doubles and FactoryGirl.build over FactoryGirl.create where possible). We also could verify if we actually need all gems we install on Travis for the tests to run.

JR

Jason Robinson Sat 8 Nov 2014

Anyway, the proposal was stupid, since I misunderstood the problem. So closing it.

Thanks for clarifying.

DU

Dumitru Ursu Tue 6 Jan 2015

On ruby 2.2 the RSpec suite runs in 5 minutes on my core i5-540M (which is still slow, if you ask me). The only problem is eventmachine, you have to upgrade it.

DU

Dumitru Ursu Tue 6 Jan 2015

@jhass using factory girl objects (and stubbing those out) instead of fixtures would bring very tangible speedups to the test suite. Also, as a last resort, we can use parallel_tests: probably most of us have multicore machines.

JH

Jonne Haß Tue 6 Jan 2015

Yeah sure, we also recently cut down our cucumber suite run by a lot, by eliminating all the slow finders, there's a lot of room for optimization in the testsuite ;) We had parallel_tests once, but I don't remember the reason of why it got dumped. As for CI that would bring no benefit since Travis containers only get 1.5 CPUs. Anyway, any patches that make stuff faster are very welcome!

JH

Jonne Haß started a proposal Tue 21 Apr 2015

Drop Ruby 2.0 support, adopt Ruby 2.2 support Closed Mon 27 Apr 2015

Outcome
by Jonne Haß Tue 25 Apr 2017

No objections, accepted. The next major version will implement these changes.

  • Official security maintenance for Ruby 2.0 will end February 24 2016.
  • Rails 5 will support Ruby 2.2 only.
  • Ruby 2.1 and 2.2 have largely improved garbage collection over Ruby 2.0.
  • Ruby 2.1 added required keyword arguments which can't be used as a useful tool towards more correct code when supporting Ruby 2.0

Results
Agree - 10
Abstain - 10
Disagree - 10
Block - 10
12 people have voted (20%)
JH

Jonne Haß
Agree
Tue 21 Apr 2015

DS

Dennis Schubert
Agree
Tue 21 Apr 2015

no objections

S

SuperTux88
Agree
Tue 21 Apr 2015

DU

[deactivated account]
Agree
Tue 21 Apr 2015

F

Faldrian
Abstain
Tue 21 Apr 2015

have no productive pod, but seems reasonable :)

F

Flaburgan
Agree
Tue 21 Apr 2015

SVB

Steffen van Bergerem
Agree
Tue 21 Apr 2015

DU

[deactivated account]
Agree
Wed 22 Apr 2015

A

aj
Agree
Sat 25 Apr 2015

easy enough for us podmins using RVM to handle and i think most of the shared hostings will run ruby 2.1 now

FS

Florian Staudacher
Agree
Sat 25 Apr 2015

JR

Jason Robinson
Agree
Sun 26 Apr 2015

MŁ

Maciek Łoziński
Abstain
Mon 27 Apr 2015