9 ms·
That sounds like a major, incredibly dangerous update to the DB driver. Their 7.1, 7.2, 7.3 versions seem to all have breaking changes [1]. Yet they are in obv
by ricardobeat 5y ago
That sounds like a major, incredibly dangerous update to the DB driver. Their 7.1, 7.2, 7.3 versions seem to all have breaking changes [1].
Yet they are in obvious violation of SemVer expectations, which they declare to follow [2]:
> Mongoid follows versioning guidelines as outlined by the Semantic Versioning Specification, so you can expect only backwards incompatible changes in major versions [sic]
[1] https://docs.mongodb.com/mongoid/current/tutorials/mongoid-upgrade/#logical-operations https://docs.mongodb.com/mongoid/current/tutorials/mongoid-u...
[2] https://mongoid.github.io/old/en/mongoid/docs/upgrading.html https://mongoid.github.io/old/en/mongoid/docs/upgrading.html
- BlackFingolfin 5y agoTo be fair, the your second link points to the documentation of an ancient version; the new docs don't seem to mention semver (I still don't think what they are doing is reasonable, but ...)
- ricardobeat 5y agoThat link is reachable from their home page right now, under “Upgrading”. EDIT: just noticed the docs I found via Google are marked as “old” in the URL: https://mongoid.github.io/old/en/mongoid/ https://mongoid.github.io/old/en/mongoid/ Are you suggesting they dropped semver in between these releases?
- dragonwriter 5y ago> Mongoid follows versioning guidelines as outlined by the Semantic Versioning Specification, so you can expect only backwards incompatible changes in major versions I will note that this reverses the direction of implications. In SemVer, you should expect breaking changes only in major versions. (All version changes with breaking changes should be major, but nonbreaking changes can occur in major or minor versions.) This is not the same as expecting only breaking changes in major versions. (Which would mean all changes in major versions should be breaking, nonbreaking changes cannot occur in major versions, and breaking changes might still occur in minor versions.) .
- munificent 5y agoI'm guessing the sentence they wrote is just a consequence of English not being the author's primary language. I frequently see ESL speakers get adjective and adverb positions wrong in ways that unintentially change the meaning. Even skilled English speakers make mistakes here because English is both very permissive about word order, but also tends to give different shades of meaning to each other. "Only" is a pernicious one. When I got my last book copyedited, fixing the location of "only" was one of the most common changes.
- jzwinck 5y agoThere is a real parallel between this mistake and the or() mistake. As a native English speaker I glossed over both of them at the first reading.
- thaumasiotes 5y ago> When I got my last book copyedited, fixing the location of "only" was one of the most common changes. I remember a puzzle which presented a (fairly long) sentence and asked "provide a word that can be correctly inserted at any point in this sentence". The answer was "only". (Of course the meaning would change according to where the "only" was placed, but still... you'd have a hard time inserting "experience" at every position of a sentence.)
- 5y ago
- Railsify 5y agoSemantic Versioning does not mean you can update without reading the changelog. Blame here remains with the developer who updated without reading the changelog.
- deleted 5y ago[deleted]
- kinduff 5y agoLearned this the hard way. No matter the change or version, I always try to double check both CHANGELOG and the commits.
- montblanc 5y agoI think tests should have caught that one but I agree.
- henry700 5y agoNot if you follow the One True Way of Unit Testing (tm) where the Mongoid lib would have been mocked away, and the test would pass :) Integration tests might've done the job here.
- montblanc 5y agoYou dont mock the db layer, i dont do that at least, hell no. Let the db be hit, check that the records it returns make sense. Thats how I roll at least.
- henry700 5y agoDidn't want to aim at you with the reply, just remembered the collective delusion of 100% coverage unit testing zealots and how this would ironically fail to catch this. You'd be surprised how far people go to shoot themselves in the foot.
- 5y ago
- lordgroff 5y agoYeah, semver is great, except nobody follows it. The amount of times I have updated minor or even patch releases of packages with things breaking--I have pretty much determined everything in a project stays the same unless there's some pressing need. The worst part is that breakage is often far from obvious, and spending good time wondering why everything breaks when it shouldn't is really really infuriating and makes me feel like the entire world of software is hopelessly broken.
- lamontcg 5y agoA big part of the problem with SemVer is that "breaking changes" is subjective and there's always the xkcd spacebar heating problem. The flip side of most breaking changes that are released is some software developer who either wasn't experienced enough to imagine that the change would break someone or else they're dealing with a very hard problem that they're trying to solve and the break change was collateral damage in some edge condition they didn't consider. Many people's breaking changes are someone else's bugfix, and often users fluidly wind up on either side of that condition on different bugs -- screaming about bugs that haven't been fixed for years and then screaming about other bugfixes that broke them.
- lordgroff 5y agoHere's a recent example from sqlalchemy. I'm using a type annotation. Update to new minor version. BAM, annotation no longer works, the classes have moved around and I'm staring at an ugly exception. To be clear: these were not private modules, methods, what have you. So we're not talking about the space bar issue here, it wasn't some undocumented or buggy behavior, things just stopped working as the API got shuffled around. At that point this was literally the third semver breakage in the same month, and yeah, this is unusual, but dependencies have stayed fixed since then, it's a headache and it makes me feel like everything is just built on a pile of shifting sand.
- lamontcg 5y agoThat's probably because its open source and the Patreon contributions don't compare well to a FAANG staff SDE salary. SemVer is highly constraining and its a PITA to work with when you're getting a 6-figure salary. TANSTAAFL.
- Gigachad 5y agoTbh when you work with ruby to have to assume everything could break with any update and just unit test the shit out of everything. Of course it’s easy to miss something, but unit tests could have caught this issue. It's still just really bad work from the gem developers though. Ideally you shouldn't ever drastically change the behavior of a method. Just introduce it again with a new name and remove the old one. Yeah it might not be as nice, but it avoids triggering $73,000 worth of incorrect transactions.
- emodendroket 5y agoUltimately this is why I don't like to work in Ruby. You can just never trust any line of code between the gem updates, the unhelpful signatures, the overreliance on hashes everywhere, and a million different levels of mix-ins and indirection. Yeah, it's expressive, but how much time are you really saving once you consider all these maintenance headaches?
- joelbluminator 5y agoThis is quite rare and also types would have done nothing in this case.
- stouset 5y agoThis exact problem could have happened in any language. Literally zero of it has to do with Ruby or the ecosystem.