5 ms·

We use Mongoid. I treat every upgrade, no matter how small as its own piece of work involving going through the changelogs with a fine-tooth comb. This particul

We use Mongoid. I treat every upgrade, no matter how small as its own piece of work involving going through the changelogs with a fine-tooth comb. This particular issue got flagged up when we last looked at upgrading. Currently Mongoid upgrades are stalled until we have the time to figure out the impact of some of their more egregious changes. I have a generally low trust approach to all dependency upgrades, irrespective of how minor they are, I've been bitten by enough "minor" changes. But I treat Mongoid as an active adversary who is setting out to break things with every update. It's the complete opposite approach to that of the Rails core team and those that work on ActiveRecord (as the nearest equivalent to Mongoid). Changes to Rails core are always well flagged with really good advance warning of upcoming breaking changes, frequently with deprecation warnings several versions in advance. There just seems to be a core culture of thought and care towards their users.

jacquesm 5y ago
This is part of the TCO of any major software project, kudos for getting it right, that's a very mature process you have there.
nefitty 5y ago
I feel spoiled having most of my experience in js, react and node. They like, try really hard not to totally break shit.
- fouc 5y ago
  You would feel spoiled if you were a ruby developer too. This type of library API breaking change on a minor version update basically never happens. And if it can happen in ruby land, it can happen in JS land too.
  - weaksauce 5y ago
    i mean the whole lpad debacle was pretty egregious and that's directly in the javascript land
  - deleted 5y ago
    [deleted]
  - astrowilson 5y ago
    > This type of library API breaking change on a minor version update basically never happens. Literally happens all the time with Rails. To the point they decided to call their versioning schema “shifted semver” to afford themselves API changes on minor versions: https://guides.rubyonrails.org/maintenance_policy.html https://guides.rubyonrails.org/maintenance_policy.html Good luck if you are using Rails and ecosystem and you expect any sort of sensible versioning.
    - chucke 5y ago
      Rails never was semver. Their yearly major-minor grand release always, always breaks API all around. It's inevitable. Any rails-only gem will as a result have a strong incentive not to follow several.
    - byroot 5y ago
      Rails committer here. First I get that people are used to SemVer, but it is unreasonable to assume all projects follow it. And yes in semver terms, you can simply assume that Rails X.Y is a major release. Then, any breaking change in Rails must first emit deprecation warnings, so unless you are jumping one version, this kind of scenario shouldn't happen with Rails itself. Also note that Ruby (MRI) itself more or less behave the same regarding versioning, deprecations and breaking changes. First emit warnings, then break.
      - astrowilson 5y ago
        That’s precisely my point. With Rails and Ruby breaking APIs on every new minor release, the only realistic expectation is that every minor release of anything may have breaking changes, because that’s the example being set. And it just makes the experience of updating any Rails project even worse than it already is. The language and framework, by your own statement, are pushing breaking changes at a yearly rate. That’s a horrible developer experience.
        byroot 5y ago
        No the expectation is that users of projects stop assuming SemVer is followed by every projects. > pushing breaking changes at a yearly rate. That’s a horrible developer experience. That's your opinion. I much prefer these bite sized yearly changes to much bigger changes over longer periods. e.g. Ruby with this strategy never had the big divide Python 3 had with its much larger change.
- rgoulter 5y ago
  Well, except for leftpad.
jrochkind1 5y ago
That sure doesn't seem to be an endorsement of mongoid.
- dsjoerg 5y ago
  It wasn't meant to be. But in a way it is -- mongoid is so useful, that it's worth putting up with some of the flaws in its release/upgrade management. So, it's temperamental. Like owning a Jaguar.
- noneeeed 5y ago
  It isn't. We have used Mongo for good reasons, it's been appropriate for our workload, and we have used Mongoid since the inception of the product long before I joined the company. Replacing Mongoid at this stage would be a massive piece of work. I find Mongoid's documentation is vague and lacks important detail, and the API itself violates the principal of least surprise frequently enough to be a problem. It really is the ugly stepchild of ActiveRecord, in whose image it was created, and which by comparison has been a pleasure to both use and to manage.

jacquesm 5y ago

This is part of the TCO of any major software project, kudos for getting it right, that's a very mature process you have there.

nefitty 5y ago

I feel spoiled having most of my experience in js, react and node. They like, try really hard not to totally break shit.

fouc 5y ago
You would feel spoiled if you were a ruby developer too. This type of library API breaking change on a minor version update basically never happens. And if it can happen in ruby land, it can happen in JS land too.
- weaksauce 5y ago
  i mean the whole lpad debacle was pretty egregious and that's directly in the javascript land
- deleted 5y ago
  [deleted]
- astrowilson 5y ago
  > This type of library API breaking change on a minor version update basically never happens. Literally happens all the time with Rails. To the point they decided to call their versioning schema “shifted semver” to afford themselves API changes on minor versions: https://guides.rubyonrails.org/maintenance_policy.html https://guides.rubyonrails.org/maintenance_policy.html Good luck if you are using Rails and ecosystem and you expect any sort of sensible versioning.
  - chucke 5y ago
    Rails never was semver. Their yearly major-minor grand release always, always breaks API all around. It's inevitable. Any rails-only gem will as a result have a strong incentive not to follow several.
  - byroot 5y ago
    Rails committer here. First I get that people are used to SemVer, but it is unreasonable to assume all projects follow it. And yes in semver terms, you can simply assume that Rails X.Y is a major release. Then, any breaking change in Rails must first emit deprecation warnings, so unless you are jumping one version, this kind of scenario shouldn't happen with Rails itself. Also note that Ruby (MRI) itself more or less behave the same regarding versioning, deprecations and breaking changes. First emit warnings, then break.
    - astrowilson 5y ago
      That’s precisely my point. With Rails and Ruby breaking APIs on every new minor release, the only realistic expectation is that every minor release of anything may have breaking changes, because that’s the example being set. And it just makes the experience of updating any Rails project even worse than it already is. The language and framework, by your own statement, are pushing breaking changes at a yearly rate. That’s a horrible developer experience.
      - byroot 5y ago
        No the expectation is that users of projects stop assuming SemVer is followed by every projects. > pushing breaking changes at a yearly rate. That’s a horrible developer experience. That's your opinion. I much prefer these bite sized yearly changes to much bigger changes over longer periods. e.g. Ruby with this strategy never had the big divide Python 3 had with its much larger change.
rgoulter 5y ago
Well, except for leftpad.

jrochkind1 5y ago

That sure doesn't seem to be an endorsement of mongoid.

dsjoerg 5y ago
It wasn't meant to be. But in a way it is -- mongoid is so useful, that it's worth putting up with some of the flaws in its release/upgrade management. So, it's temperamental. Like owning a Jaguar.
noneeeed 5y ago
It isn't. We have used Mongo for good reasons, it's been appropriate for our workload, and we have used Mongoid since the inception of the product long before I joined the company. Replacing Mongoid at this stage would be a massive piece of work. I find Mongoid's documentation is vague and lacks important detail, and the API itself violates the principal of least surprise frequently enough to be a problem. It really is the ugly stepchild of ActiveRecord, in whose image it was created, and which by comparison has been a pleasure to both use and to manage.