From my gem file:
#Spring speeds up development by keeping your application running in the background. Read more: GitHub - rails/spring: Rails application preloader
I’ve just removed it!! Had lots of weird issues with my app all day (like config data not persisting) removed Spring and it seems fine now touch wood.
Anyone else using it?
I believe the term is “knock on wood” otherwise it’s rather inappropriate.
I have ‘spring’ only as a development dependency but I don’t even believe I’m using it. It was included by the default rails generation and I’m sure I’d be fine removing it as well. But I haven’t seen any problems. Gemfile.lock has spring at 1.6.1
I’m using Puma on both dev and prod and use “rails s” for running my local setup. No issues this way for me.
We use ‘touch wood’ here 
Maybe you haven’t started it up? Try spring stop - if it’s already stopped it will say.
WEBrick 1.3.1 - here. Is Puma the default server for Rails 5? I vaguely remember some talk about the server being changed for Rails 5.
@AstonJ just readded spring again to 2 apps, because I wanted to try it again and see if the issues I had were resolved.
Its a great speedup for our specs, so we don’t have to boot rails every time we want to execute a spec.
And yes puma is the new default webserver for rails 5 because of actioncable 
spring stop will say it stopped when Rails isn’t running and when I run my dev env of rails s and then run sprint stop it says spring isn’t running.
Just now I’ve gone ahead and commented out that gem along with sdoc and jbuilder since having less gems is better.
I don’t use Rails 5. They do too many changes to Arel between Rails minor versions. I’m using http://jsonapi.org/ with JR on Rails 4+.
I think it was code reloading for the specs.
Specs were red, implemented stuff → should work, still red, after restarting spring green 
Seems like this is not the source of the problem after all - it’s back. Really frustrating.
I am using it in development and it works fine for me.
I don’t use spring for running spec though.