4 ms·

We're just trading anecdotes at this point but I can't say I've encountered the same problems over the past decade of working with it. That's generally because

by ljm 5y ago

We're just trading anecdotes at this point but I can't say I've encountered the same problems over the past decade of working with it. That's generally because of limiting dependencies, but also because it's a good idea to peek at the changelog or release notes when bumping the minor or major version. TFA doesn't mention or acknowledge this aspect of the issue, but it did surprise me that they considered a version bump from 7.0.8 to 7.3.3 to be innocent looking. In fact, these 'minor' releases actually appear to be quite significant and the issue in question in TFA was explicitly documented. [0][1] I hate to say it but this was just a case of sloppy work on the startup's part. It took me less than 5 minutes to find that info. [0] https://docs.mongodb.com/mongoid/current/tutorials/mongoid-upgrade/#logical-operations https://docs.mongodb.com/mongoid/current/tutorials/mongoid-u... [1] https://github.com/mongodb/mongoid/releases/tag/v7.1.0 https://github.com/mongodb/mongoid/releases/tag/v7.1.0

newaccount74 5y ago
It took you 5 minutes to find the info because you knew what you were looking for. Expecting programmers to audit all of their code before a minor update is ridiculous.
- ljm 5y ago
  'Auditing all your code' isn't the same as looking up the changes for a certain version on its github release page or a changelog page (if it has one). It's not the responsibility of OSS maintainer to ensure your software still functions after an upgrade if you're not even willing to spend a modicum of effort to hold up your own end of that bargain. This isn't a big ask, it's why there are changelogs and release notes in the first place; they make it so you don't have to audit the code every time the version changes. If you're not willing to do that and want unattended upgrades for all dependencies, then this is where the 'no warranty' aspect of that OSS license comes in.
  - Gigachad 5y ago
    >It's not the responsibility of OSS maintainer The OSS maintainer has no responsibilities at all so you are right. But if anyone was to blame, it's certainly the library. It's outrageous to radically change a function while keeping the name the same. Because of exactly this issue. If they renamed it you would get an exception which is much nicer.
  - deleted 5y ago
    [deleted]
- losvedir 5y ago
  Seriously? It's eminently reasonable to expect you to know the code you're deploying. Perhaps you're a JS developer. I agree it's incredibly difficult to keep up with the churn there, but in my Elixir deps, the updates tend to be less frequent and more reviewable. Some deps you can trust the owner and just carefully review the change log. Even that would have caught this issue, though I'm not sure I'd count this gem as trustworthy.
  - newaccount74 5y ago
    I'm not a JS developer, I'm just someone who has shipped enough software to know that the fraction of people reading change logs is vanishingly small. Maybe you are a very careful developer, but the vast majority out there is not. Shipping an udate that will corrupt data if you don't read the changelog is very very dangerous. I see why they did it. Having a method with the same name as in Active Record but with different behavior is also dangerous. But they really could have handled this better.
- ricardobeat 5y ago
  The NPM mindset.
- blindmute 5y ago
  I'd say that updating any version of anything, without reading the changelog, is irresponsible. Why are you updating a gem if you have no idea what has changed?
  - emodendroket 5y ago
    In other programming environments people do this without issue routinely.
    - ljm 5y ago
      I used to do this, especially with patch releases. Just bump the version and hope the build passes. My mindset has gradually shifted over time though. These days, it's more a case of updating one thing at a time, and doing the research up front to see what I'm gaining from it or if I might as well stay on the current version. No point updating for the sake of it. That's 5-10 minutes of up-front, preventative effort that might otherwise become hours of reactive firefighting, and as much time spent on damage control, if it got into production unchecked.
phendrenad2 5y ago
Yes, this is just part of life. Most open-source developers go well beyond the technically-correct "I don't owe you anything" stance and actively try to help their users, which includes adhering to SemVer, and trying to do more work so that the user doesn't have to. However, you can't rely on this. Many open-source projects fill a niche and become popular when it isn't the intention of the author. This causes a disconnect where the users expect the project to be for them, when the project is really for the author. Mongoid seems to be more in the former category (for the user). Because some libraries are badly managed, you need to audit all of them.

by ljm 5y ago

newaccount74 5y ago

It took you 5 minutes to find the info because you knew what you were looking for. Expecting programmers to audit all of their code before a minor update is ridiculous.

ljm 5y ago
'Auditing all your code' isn't the same as looking up the changes for a certain version on its github release page or a changelog page (if it has one). It's not the responsibility of OSS maintainer to ensure your software still functions after an upgrade if you're not even willing to spend a modicum of effort to hold up your own end of that bargain. This isn't a big ask, it's why there are changelogs and release notes in the first place; they make it so you don't have to audit the code every time the version changes. If you're not willing to do that and want unattended upgrades for all dependencies, then this is where the 'no warranty' aspect of that OSS license comes in.
- Gigachad 5y ago
  >It's not the responsibility of OSS maintainer The OSS maintainer has no responsibilities at all so you are right. But if anyone was to blame, it's certainly the library. It's outrageous to radically change a function while keeping the name the same. Because of exactly this issue. If they renamed it you would get an exception which is much nicer.
- deleted 5y ago
  [deleted]
losvedir 5y ago
Seriously? It's eminently reasonable to expect you to know the code you're deploying. Perhaps you're a JS developer. I agree it's incredibly difficult to keep up with the churn there, but in my Elixir deps, the updates tend to be less frequent and more reviewable. Some deps you can trust the owner and just carefully review the change log. Even that would have caught this issue, though I'm not sure I'd count this gem as trustworthy.
- newaccount74 5y ago
  I'm not a JS developer, I'm just someone who has shipped enough software to know that the fraction of people reading change logs is vanishingly small. Maybe you are a very careful developer, but the vast majority out there is not. Shipping an udate that will corrupt data if you don't read the changelog is very very dangerous. I see why they did it. Having a method with the same name as in Active Record but with different behavior is also dangerous. But they really could have handled this better.
ricardobeat 5y ago
The NPM mindset.
blindmute 5y ago
I'd say that updating any version of anything, without reading the changelog, is irresponsible. Why are you updating a gem if you have no idea what has changed?
- emodendroket 5y ago
  In other programming environments people do this without issue routinely.
  - ljm 5y ago
    I used to do this, especially with patch releases. Just bump the version and hope the build passes. My mindset has gradually shifted over time though. These days, it's more a case of updating one thing at a time, and doing the research up front to see what I'm gaining from it or if I might as well stay on the current version. No point updating for the sake of it. That's 5-10 minutes of up-front, preventative effort that might otherwise become hours of reactive firefighting, and as much time spent on damage control, if it got into production unchecked.

phendrenad2 5y ago

Yes, this is just part of life. Most open-source developers go well beyond the technically-correct "I don't owe you anything" stance and actively try to help their users, which includes adhering to SemVer, and trying to do more work so that the user doesn't have to. However, you can't rely on this. Many open-source projects fill a niche and become popular when it isn't the intention of the author. This causes a disconnect where the users expect the project to be for them, when the project is really for the author. Mongoid seems to be more in the former category (for the user). Because some libraries are badly managed, you need to audit all of them.