Different travis job for Rails versions: 3.2 4.0 4.1 4.2

[ch1ago]

@jejacks0n do you think you can take this from here?

[ch1ago]

Github was going through a DDOS attack, so would you also mind rerunning the travis build?

[mikepack]

Have you considered using appraisal to handle the Gemfile creation?

FYI: I foresee this conflicting with @jejacks0n WIP branch: https://github.com/modeset/teaspoon/pulls

[ch1ago]

@mikepack I didn't realize @jejacks0n had a WIP branch when I started this, when I saw it I threw the ball at him (if memory recalls, this is our fourth interaction in open source)

I just came across this gem a few days ago and loved it so much I wanted to make sure it would optimize adoption rates. I am very proactive when it comes to secure things I care about.

Great work on this gem, front-end feels like back-end again :wink:

[ch1ago]

@mikepack yeah, @jejacks0n should be the one to merge this. We have a tiny history, I believe this is our fourth interaction in open source. Great gem, I just learned about it a few days ago and I loved it. So I wanted to make sure adoption rate is always optimal when it comes to version compatibility. Great work ;)

[jejacks0n]

hey @thejamespinto! thanks, this is nice.

I can't really merge this cleanly right now, but I'll revisit it when I get a chance, does that work for you? I will probably take an approach that doesn't include the various gemspecs as well -- I've found it confuses some people, especially if they inadvertently make it into the gem package.

[jejacks0n]

I'll leave this open for the time being until I can revisit it.

[ch1ago]

@jejacks0n hey, well, having separate files seems like the most logical and organized thing for me, whereas having a crazy conditional dependency structure seems like hell :sweat_smile: Yes, the approach works for me, I wouldn't have created a bad PR on purpose. However, there was one single spec that failed, so I assumed you would know how to fix it. I loved this gem, just do me a favor and make it run on various Rails versions so people will always be able to adopt it and update it :wink:

[jejacks0n]

That’s fair. I think the way I’ve seen it before that I liked was setting a RAILS_VERSION env that is used in the Gemfile (with a fallback). Then you can set a matrix of those versions pretty much the same way you have in the .travis.yml.

The problem I see with teaspoon is that it’s been generally painful because of sprockets updates, not rails updates — but not isolated to sprockets entirely, but yes, I agree that testing it on multiple versions of rails is critical. Additionally, it’s not going to be so much a part of teaspoon proper, but rather something that each of the frameworks will focus on, since those are the “end to end” implementations of jasmine, mocha, etc.

I very much appreciate your work, it was just bad timing on when it went in — and we’ll try and address this and get the concept in where it fits as soon as we’re done with the 1.0.0 push. Thanks again!

---

Jeremy Jackson

On Apr 4, 2015, at 9:22 PM, James Pinto notifications@github.com wrote:

@jejacks0n https://github.com/jejacks0n hey, well, having separate files seems like the most logical and organized thing for me, whereas having a crazy conditional dependency structure seems like hell
Yes, the approach works for me, I wouldn't have created a bad PR on purpose. However, there was one single spec that failed, so I assumed you would know how to fix it. I loved this gem, just do me a favor and make it run on various Rails versions so people will always be able to adopt it and update it

— Reply to this email directly or view it on GitHub https://github.com/modeset/teaspoon/pull/335#issuecomment-89710465.

[mikepack]

Hey @thejamespinto. I'm going to close this for now. I've added an issue (#348) that we will eventually get to once things have stabilized a bit more (read: post-1.0 release).

Your contribution is hugely appreciated, and we'll probably reference this PR when we work this into the codebase. :heart: :heart: :heart: