Gem updates

[clemens]

#64 but without the change to Puma and keeping the start/stop commands.

[tyler-mauthe-hs]

Hello again! This looks great, except a few of the gems aren't compatible with crusty old ruby 2.1.10.

Support for Ruby 2.1 ended in April: https://www.ruby-lang.org/en/news/2017/04/01/support-of-ruby-2-1-has-ended/

We also have no testing of 2.4.x -- the latest minor revision is 2.4.1.

We could modify the RVM versions we ask Travis to test with here:
https://github.com/Smashing/smashing/blob/master/.travis.yml#L5

@kinow -- what do you think? What ruby versions should we officially support?

[kinow]

Would be easier if it was 1.9 and 2.0. This week I've returned to a company where there is one server with a Ruby application running 1.9 on SLES 11, but is migrating to new servers with RHEL 7, which includes 2.3 (I think it's 2.3.x ? don't have access to the repositories right now to confirm).

I wouldn't suggest supporting 1.9. At home I have 2.3 in Ubuntu. Checking some of the few gems I am familiar with in Ruby, here's what I could find:

• haml - 2.0+
• nokogiri - 2.1+
• capistrano - 2.0+
• resque - 2.0+
• capybara - 1.9.3+
• eventmachine - 1.8.7+
• mustache - 2.0+

So I'd say 2.0 would be a good one to support more users.... but if we don't have enough development working hours to maintain older version, then whatever comes with the LTS version of Ubuntu/Red Hat would be fine for me (i.e. 2.3 I think).

• +1 for 2.0
• +0 for 2.3
• -1 for anything before 2.0

I guess I didn't help much. Any thoughts after this @tyler-mauthe-hs ?

[clemens]

What's the value of (officially) supporting Ruby versions that aren't even supported by the Ruby core team themselves? I'm not saying that one necessarily needs to explicitly discontinue support by introducing version constraints – but taking it out of the official build matrix IMO sends the right signal.

[kinow]

Not much in our case, I agree. Passenger I believe supports even older versions of Ruby, but that's simply to allow users running older versions to still use it, without having to hack the code or find alternatives.

In our case perhaps it would make more sense to support only the latest version supported by Ruby core team. As as I said, I'm ok with going to something like Ruby 2.3. But if the cost for us to support 2.0 was low, I'd consider that option too, to allow more users to use Smashing.

[tyler-mauthe-hs]

Since the fork of Smashing, we have not supported 2.0 -- 2.1 is the oldest.

The advantage of supporting older Ruby versions is that it makes Smashing operationally simpler, so that it can be easily installed by sysadmins on whatever ancient version of linux keeps production running -- without having to learn things like RVM or rbenv.

If we had system packages (apt and RPM), we could do as Puppet and Sensu do -- install our own embedded version of Ruby.

That being said, I really think that dropping support for old and unsupported versions is the right thing to do. Before we do it, we should make a wiki page outlining how to install ruby 2.2 on CentOS 7 and Ubuntu 16.04 if it's not available as a default pacakge.

[kinow]

That being said, I really think that dropping support for old and unsupported versions is the right thing to do. Before we do it, we should make a wiki page outlining how to install ruby 2.2 on CentOS 7 and Ubuntu 16.04 if it's not available as a default pacakge.

+1, and even better if we can perhaps find some official docs from CentOS, Ubuntu, or Ruby, describing how to install Ruby 2.2.

[olleolleolle]

CentOS 7

Official docs are hard to come by.

• DigitalOcean publishes guides on Install Ruby on CentOS 7 but that one's using rbenv
• Install newer Ruby via RPM

Ubuntu 16.04

Use Brightbox-supplied packages, they have a Launchpad package repo page and everything.

See https://www.brightbox.com/docs/ruby/ubuntu/

[terraboops]

Great idea - let's link to some other docs:
https://github.com/Smashing/smashing/wiki/Installation

This line needs to be removed and then this can be merged:
https://github.com/Smashing/smashing/blob/master/.travis.yml#L5

[olleolleolle]

@tylermauthe #92 I made a thing.

[terraboops]

Hmmm - doesn't seem like my merge commit to get the travis changes onto this branch worked... I suppose because @clemens controls the fork which is being merged?

@clemens please resolve the conflicts in the branch - tests should automatically re-run and the build should be green so we can merge this. If it's unresolved in a week, I'll assume this PR is abandoned - but I can fork the fork back into the project and do surgery on it that way.

[terraboops]

Closing this PR - I've resolved the merge conflicts in #94!