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

@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...

@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).

OK thanks, both of you.

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

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

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

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

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

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

... will also decrease our travis build time somewhat

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

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

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

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?

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.

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

Thanks for clarifying.

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.

@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.

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!