4 ms·

The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the s

The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the surface this seems ok the underlying problem, as I see it, is the old version isn't maintained, so essentially the only maintained version now has breaking API changes. There are few ways this could be addressed, e.g. separate branches for old gems, and some developers do actually do this but in the end I've noticed these legacy branches and gems just bitrot while the developer devotes their time to the new branch. So essentially to use the gem you have to make the SemVer API jump which then begins the dependency failure cascade dance you mention. I'm close to starting another new Rails job and I'm not looking forward to the inevitable rails rescue work on legacy codebases, yet this is the reality of a modern Rails developer. Also I think this upgrade work needs to be factored into "development time" and when you do I'm not convinced Rails is actually faster.

busterarm 10y ago
I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and the return output of their methods are documented.
- engineerDave 10y ago
  Fair points all. But the breaking changes I'm referring to are items like changing method names, most likely because OCD, and helper methods, etc. While good/great tests will catch this type of stuff in your code, it will still be a lot of chasing your tail refactoring code because someone didn't like the way something was named. I see this a lot in the ruby community. Its like some sort of crazy insanity that ruby devs exercise when changing publicly exposed API methods just because _____. smh
  - busterarm 10y ago
    Yeah changing your method names around in a publicly-exposed API that has users on an incremental release is more than a little bit belligerent.
- borkborkbork 10y ago
  I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems: 1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage. 2) Some of the gems we depended on conflicted so severely that we had to rip them out and implement the solution ourselves or pick a different gem. 3) Our tests themselves of course contained code with breaking API changes. That means we had to maintain the tests as well as the production code through the upgrade, and had to make changes to many of those tests. All of this uncertainty means that this was not your typical test-driven confident refactor. QA still had to do massive regression testing, and we're pretty sure we introduced at least a new bug or two. It took a pair of devs 4 months of non-stop work to get these services up to Rails 4.1. The upgrade was absolutely necessary as the Rails core team had already stopped fixing major security holes in 3.1 long ago. The company incurred a tremendous cost during this upgrade process. If they would have kept things up to date all along they could've saved money, but of course that would have eaten into the supposed time-savings of Rails.
  - busterarm 10y ago
    I believe it and know that sucked, but unfortunately in Rails 3 we got caught with our collective pants down in terms of security. Nobody competent was really auditing it (as was demonstrated against Github) to match the amount of momentum that it had. I see that as more of a Black Swan event than any inherent problem with the framework (yes, I'm basically blaming its users). This wasn't typical of the Rails 2 to 3 upgrade path and doesn't look like it'll be the 4 to 5 path either...and certainly not for incremental updates.
    - engineerDave 10y ago
      I think your memory of the 2 -> 2.1 -> 2.2 -> 2.3 (if you were lucky to get bundler running) to 3 to almost immediate 3.1 with massive changes (asset pipeline) upgrade is a little fuzzy. It was the suck. A lot of companies I know of are still running Rails 2 because of this change.

busterarm 10y ago

I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and the return output of their methods are documented.

engineerDave 10y ago
Fair points all. But the breaking changes I'm referring to are items like changing method names, most likely because OCD, and helper methods, etc. While good/great tests will catch this type of stuff in your code, it will still be a lot of chasing your tail refactoring code because someone didn't like the way something was named. I see this a lot in the ruby community. Its like some sort of crazy insanity that ruby devs exercise when changing publicly exposed API methods just because _____. smh
- busterarm 10y ago
  Yeah changing your method names around in a publicly-exposed API that has users on an incremental release is more than a little bit belligerent.
borkborkbork 10y ago
I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems: 1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage. 2) Some of the gems we depended on conflicted so severely that we had to rip them out and implement the solution ourselves or pick a different gem. 3) Our tests themselves of course contained code with breaking API changes. That means we had to maintain the tests as well as the production code through the upgrade, and had to make changes to many of those tests. All of this uncertainty means that this was not your typical test-driven confident refactor. QA still had to do massive regression testing, and we're pretty sure we introduced at least a new bug or two. It took a pair of devs 4 months of non-stop work to get these services up to Rails 4.1. The upgrade was absolutely necessary as the Rails core team had already stopped fixing major security holes in 3.1 long ago. The company incurred a tremendous cost during this upgrade process. If they would have kept things up to date all along they could've saved money, but of course that would have eaten into the supposed time-savings of Rails.
- busterarm 10y ago
  I believe it and know that sucked, but unfortunately in Rails 3 we got caught with our collective pants down in terms of security. Nobody competent was really auditing it (as was demonstrated against Github) to match the amount of momentum that it had. I see that as more of a Black Swan event than any inherent problem with the framework (yes, I'm basically blaming its users). This wasn't typical of the Rails 2 to 3 upgrade path and doesn't look like it'll be the 4 to 5 path either...and certainly not for incremental updates.
  - engineerDave 10y ago
    I think your memory of the 2 -> 2.1 -> 2.2 -> 2.3 (if you were lucky to get bundler running) to 3 to almost immediate 3.1 with massive changes (asset pipeline) upgrade is a little fuzzy. It was the suck. A lot of companies I know of are still running Rails 2 because of this change.