On Tue, Sep 29, 2015 at 3:36 PM, Eric Wong <[email protected]> wrote: > Pirate Praveen <[email protected]> wrote: [...] >> It will help us a lot in maintain rails applications in debian. We >> like to keep only one version of any app/lib in debian and if you can >> guarantee Semantic Versioning rails apps using unicorn could declare a >> looser dependency rather than upto the patch version. Now gitlab >> defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are >> following Semantic Versioning they could change it to ~> 4.8 and ~> >> 4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it >> does not match ~> 4.8.3 > > Tying a Rack app to unicorn is totally, completely wrong and defeats the > point of Rack. > > Honestly, I could understand tying an app to thin with it's EM-specific > API, but unicorn(!?!?) Even if an app isn't thread-safe, it should > still work in passenger, thin, or puma/webrick configured for a > single-thread...
I guess the issue is that people need to specify which server they're using in their Gmefile when bundler is used to launch the application. I don't think it's a good idea to bind to a specific version though. Upgrading unicorn never breaks anything for me. p.s. Personally I never liked the idea of semantic versioning either, unless there's a clearly defined API like Rack's SPEC. -- unsubscribe: [email protected] archive: http://bogomips.org/unicorn-public/
