4 ms·

As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.

by wlll 4y ago

pmontra 4y ago
I have customers with a mix of small Rails projects in version 6 or 7. I told one this week that we could use AR's encrypts :field to encrypt some fields in the database, but that project is Rails 6 and that feature is added by Rails 7. We could add the code to handle it because it's small, but customer decided not to encrypt the field and wait until (if!) the project moves to Rails 7.
- wlll 4y ago
  I wouldn't say that's locked though. The place I currently work is on 6.1. We're not locked to it, we're going to upgrade, but in a few weeks or so. I can understand the reason to put off encrypting the field too. Upgrades, or backporting, are just work like any other project and I guess that other things for now take preference. After all, before field encryption came along the risk balance calculation had already been done (even if only implicitly) that storing the field unencrypted in the database was safe enough. The availability of encrypted fields doesn't change that, though making some things safer doesn't necessarily fall neatly into the "requirements" bucket despite being a good idea.
Manfred 4y ago
You have worked on a few projects that were behind a few major versions and needed considerable effort to be updated :)
- wlll 4y ago
  Sure, though I still wouldn't say they were "locked", though what that means is somewhat subjective :) There was still a will and, with a strategy, success in upgrading. I've not been anywhere that has rolled out Rails LTS for instance, or just given up. The place you worked with me last year did a Rails 6.0 -> 6.1 and it took less than a week for one person, 6.1 -> 7.0 should be pretty similar.
AlchemistCamp 4y ago
Github itself used to be. They ran a custom fork of Rails 2.3 for years rather than go through the pain of upgrading to Rails 3. By the time they finally did, Rails had already moved on. It took Github a full eight years to get caught up after that fateful decision in 2010 to hold off on Rails 3.
- wlll 4y ago
  Eileen, who used to work at Github, did a talk on the upgrade https://www.youtube.com/watch?v=ZrcPoRx_kQE https://www.youtube.com/watch?v=ZrcPoRx_kQE
- nomilk 4y ago
  What were the sticking points that made the 2.3 -> 3 upgrade so tough?
  - kodah 4y ago
    In the article they mentioned they had a lot of patches to rails. They effectively made a fork. At enterprises it can be seen as not worth it to go through getting your changes merged in because it can take a long time. Once you make that decision, you're entrenched far more than one may realize.
  - aaronbrethorst 4y ago
    2.3 -> 3 saw the Rails and Merb projects merge, and a ton of changes to remove some of the most unmaintainable magical elements of Rails. https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-rails-3-d25c7b390fa1 https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-...

As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.

by wlll 4y ago

As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.

I have customers with a mix of small Rails projects in version 6 or 7. I told one this week that we could use AR's encrypts :field to encrypt some fields in the database, but that project is Rails 6 and that feature is added by Rails 7. We could add the code to handle it because it's small, but customer decided not to encrypt the field and wait until (if!) the project moves to Rails 7.

wlll 4y ago
I wouldn't say that's locked though. The place I currently work is on 6.1. We're not locked to it, we're going to upgrade, but in a few weeks or so. I can understand the reason to put off encrypting the field too. Upgrades, or backporting, are just work like any other project and I guess that other things for now take preference. After all, before field encryption came along the risk balance calculation had already been done (even if only implicitly) that storing the field unencrypted in the database was safe enough. The availability of encrypted fields doesn't change that, though making some things safer doesn't necessarily fall neatly into the "requirements" bucket despite being a good idea.

Manfred 4y ago

You have worked on a few projects that were behind a few major versions and needed considerable effort to be updated :)

wlll 4y ago
Sure, though I still wouldn't say they were "locked", though what that means is somewhat subjective :) There was still a will and, with a strategy, success in upgrading. I've not been anywhere that has rolled out Rails LTS for instance, or just given up. The place you worked with me last year did a Rails 6.0 -> 6.1 and it took less than a week for one person, 6.1 -> 7.0 should be pretty similar.

AlchemistCamp 4y ago

Github itself used to be. They ran a custom fork of Rails 2.3 for years rather than go through the pain of upgrading to Rails 3. By the time they finally did, Rails had already moved on. It took Github a full eight years to get caught up after that fateful decision in 2010 to hold off on Rails 3.

wlll 4y ago
Eileen, who used to work at Github, did a talk on the upgrade https://www.youtube.com/watch?v=ZrcPoRx_kQE https://www.youtube.com/watch?v=ZrcPoRx_kQE
nomilk 4y ago
What were the sticking points that made the 2.3 -> 3 upgrade so tough?
- kodah 4y ago
  In the article they mentioned they had a lot of patches to rails. They effectively made a fork. At enterprises it can be seen as not worth it to go through getting your changes merged in because it can take a long time. Once you make that decision, you're entrenched far more than one may realize.
- aaronbrethorst 4y ago
  2.3 -> 3 saw the Rails and Merb projects merge, and a ton of changes to remove some of the most unmaintainable magical elements of Rails. https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-rails-3-d25c7b390fa1 https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-...