[deleted]
A routine gem update ended up creating $73k worth of subscriptions
281–290 of 336 posts
Re: A routine gem update ended up creating $73k worth of subscriptions
#282The mongoid repository ( https://github.com/mongodb/mongoid ) doesn't have issues turned on and instead points people to JIRA. That's one way to avoid users reporting issues like this - I'd see JIRA and "nope" right out.
My favorite example is Zendesk. They’re a customer support company with all their GitHub issues turned off, forcing you to use their support system. Of course, if you email them telling them they broke their library (for the 3rd time this year) and forget to email them on your account holder email they’ll respond that they only take requests from the designated email, and say goodbye.
Even when you use the right email you’re still playing telephone between some poor support person and a dev. Absolute trash-tier company, I have a backlog item to completely scrap their SDK from my apps I just haven’t gotten around to it.
Re: A routine gem update ended up creating $73k worth of subscriptions
#283Using mongodb for anything but pet projects is like drunk driving. It's fast and fun, but when you eventually crash and burn you get no sympathy. And people do get hurt.
I am joking of course :D
Re: A routine gem update ended up creating $73k worth of subscriptions
#284Earlier quoted context omitted.
It's clearly a breaking change how a core feature of the library behaves. This is extremely unprofessional on the part of the maintainers. I'd completely lose trust in the gem. They knew they were making a breaking change, documented it, and didn't increment a major version number. That breaks the entire point of semver. Also, this is generating SQL ffs. Like how more nasty of a breaking change could you make in term…
All dependency changes are changes. And changes should be tested before being deployed. If you update your dependencies and ship it based on version numbers alone, you can’t blame the maintainers
Purely in terms of the comment you're replying to, it doesn't matter whether or not the consuming app should have had or done more testing. It also doesn't matter whether or not they should have checked the documentation or change logs for the dependencies.
The isolated point the commenter was making is that a dangerous breaking change was introduced without the versioning reflecting that fact.
Both these things can be true, and any failure on the part of the startup does not remove the failure of the package versioning. These things are not contradictory so yes, you can blame the maintainers (also) as the guilt or otherwise of the startup does not alter the original versioning fail.
Re: A routine gem update ended up creating $73k worth of subscriptions
#285Three easy lessons: 1. Don't use MongoDB. 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres. 3. Especially don't use Mongoid.
> 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. In my experience using any ORM will bite you sooner or later and you'll end up bypassing it and writing SQL manually. Last case we had were a couple queries that went from double digit seconds to instant as we rewrote them natively.
Both have their place. I agree that for complex queries, nothing beats raw SQL. However, for simple, straightforward queries fetching data from a single table without JOINs/etc, the ORM is generally easier.
Re: A routine gem update ended up creating $73k worth of subscriptions
#286Earlier quoted context omitted.
If Postgres feels too heavy, don't worry! Just use SQLite, and swap in Postgres later once you need to.
I guess this is a Rails thing where people treat the db as a just dumb store.
Do you have any resources you can recommend about using the DB for more than just a dumb datastore?
The first thing I'd be concerned about is how do you manage changes? Code is easy to version control, deploy and roll-back. Database state and things such as triggers, stored procedures, etc, less so.
Re: A routine gem update ended up creating $73k worth of subscriptions
#287Earlier quoted context omitted.
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 bu…
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.
The NPM mindset.
Re: A routine gem update ended up creating $73k worth of subscriptions
#288Earlier quoted context omitted.
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…
I don't use Ruby. Are packages that don't follow semver allowed to be released? Haskell asks for PVP for example.
Yes, you'd need an automated way to catch the API breakage, which would be particularly tricky.
And even with very strict typing, the breaking change showcased in the article wouldn't have been caught, the API stayed the same, it just behave differently. Not every backward incompatible change is as simple as a function signature change.
Re: A routine gem update ended up creating $73k worth of subscriptions
#289The mongoid repository ( https://github.com/mongodb/mongoid ) doesn't have issues turned on and instead points people to JIRA. That's one way to avoid users reporting issues like this - I'd see JIRA and "nope" right out.
Is JIRA that bad even for just logging an issue? Or do you nope out of the dependency?
It really is "that bad".
JIRA is not made for humans.
Re: A routine gem update ended up creating $73k worth of subscriptions
#290Earlier quoted context omitted.
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.
You may not believe this, but there are other ways of versioning software beyond breaking things every year and doing whatever Python 3 did.
> You may not believe this
You may not need to be confrontational...
> there are other ways of versioning software
I'm sure there is. But some features and other improvements sometimes require to deprecate and remove some older features.
Each project will chose its own tradeoff between bringing the improvement faster vs keeping compatibility longer.