6 ms·

I disagree. If it works once, it works. We're running on Rails 2.3, have been for two years, and have no plans to upgrade. I can't imagine any extra feature we'

I disagree. If it works once, it works. We're running on Rails 2.3, have been for two years, and have no plans to upgrade. I can't imagine any extra feature we'd need from the framework; if so, we build it ourselves. We've hacked Rails up to fit our needs, and I think that's the way it should be.

zdw 15y ago
Replace "Rails 2.3" with "IE 6" or "Windows XP" and you have enterprise software. Yes, you have the code for Rails and can fix/make changes, but the further you deviate from what other people are fixing bugs in, the less you benefit from using open source.
- joshuaxls 15y ago
  No. In the case of IE 6 or Windows XP it's been shipped to millions of users and they have to go through the trouble of upgrading themselves. Besides, those are platforms, not frameworks. If there's a bug or security hole in Rails 2.3, we go in and fix it for our users and ship it immediately.
  - zdw 15y ago
    The point being that you have work to backport the fix, whereas keeping up with current other people fix it for you, and more eyes see it, so the fix is more likely correct. Forking off your own special version of something is a recipe for eventual pain when keeping up the old version is worse than upgrading.
swanson 15y ago
We thought this was the case as well for some internal apps using an ancient version of Rails. The problems start to arise when you bring in new people to work on improvements to the project after the creators are gone. It is much easier to find someone that knows Rails 3 than to find someone who can dive into Rails 1/2 code. You have to know what the patterns of that "era" were and be aware of bugs and subtle differences that have been ironed out as the project matured. Imagine trying to find a blog post explaining why your 4 year old version of an image upload gem doesn't work on JRuby. It's no fun :)
- kappaknight 15y ago
  > Imagine trying to find a blog post explaining why your 4 year old version of an image upload gem doesn't work on JRuby. It's no fun :) This really depends if you are running a hobby on a server, or running a business. I update client side apps cause it is exciting and it doesn't matter to me if it breaks. If it does, we cry foul and the developer updates a patch hopefully within a few days or weeks. On a production environment, this is much different. There's a reason why people say "if it ain't broke, don't try to fix it." A down time of 5 minutes could cost one company thousands while another company millions. If the cash printing machine is down, having a broken image uploader would be the least of their concerns.
groby_b 15y ago
Because you really don't care about getting fixes for security vulnerabilities? Or you have your own infosec team that tracks every single fix in Rails3 and backports it?

zdw 15y ago

Replace "Rails 2.3" with "IE 6" or "Windows XP" and you have enterprise software. Yes, you have the code for Rails and can fix/make changes, but the further you deviate from what other people are fixing bugs in, the less you benefit from using open source.

joshuaxls 15y ago
No. In the case of IE 6 or Windows XP it's been shipped to millions of users and they have to go through the trouble of upgrading themselves. Besides, those are platforms, not frameworks. If there's a bug or security hole in Rails 2.3, we go in and fix it for our users and ship it immediately.
- zdw 15y ago
  The point being that you have work to backport the fix, whereas keeping up with current other people fix it for you, and more eyes see it, so the fix is more likely correct. Forking off your own special version of something is a recipe for eventual pain when keeping up the old version is worse than upgrading.

swanson 15y ago

We thought this was the case as well for some internal apps using an ancient version of Rails. The problems start to arise when you bring in new people to work on improvements to the project after the creators are gone. It is much easier to find someone that knows Rails 3 than to find someone who can dive into Rails 1/2 code. You have to know what the patterns of that "era" were and be aware of bugs and subtle differences that have been ironed out as the project matured. Imagine trying to find a blog post explaining why your 4 year old version of an image upload gem doesn't work on JRuby. It's no fun :)

kappaknight 15y ago
> Imagine trying to find a blog post explaining why your 4 year old version of an image upload gem doesn't work on JRuby. It's no fun :) This really depends if you are running a hobby on a server, or running a business. I update client side apps cause it is exciting and it doesn't matter to me if it breaks. If it does, we cry foul and the developer updates a patch hopefully within a few days or weeks. On a production environment, this is much different. There's a reason why people say "if it ain't broke, don't try to fix it." A down time of 5 minutes could cost one company thousands while another company millions. If the cash printing machine is down, having a broken image uploader would be the least of their concerns.

groby_b 15y ago

Because you really don't care about getting fixes for security vulnerabilities? Or you have your own infosec team that tracks every single fix in Rails3 and backports it?