Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "semantic versioning"
Fuck npm and the whole npm community!
Seriously, what a piece of completely uncontrolled cat litter!
First experience was getting malware from an npm package which I ranted about a while ago. That it can even happen is beyond my imagination.
Second experience was today when our app broke because a fucker who wrote a library doesn't understand semantic versioning.
If you're gonna publish an npm library, please do the whole fucking world a favour and learn how to version your shit correctly, so my app doesn't break! If you do BREAKING CHANGES don't change the fucking last version number you filthy piece of garbage!
Phew, that felt good 😧3
I was working with a stable installation of an elaborated platform. Some plugins were installed. After upgrading the installation by 2 patch level the customer registration was not working anymore.
In these two patch level a method in an interface got an additional optional parameter which had a major impact on the behaviour the implemented method. A plugin decorated the implementation without knowing about the new parameter. Therefore when calling the method the decorating class did not pass the new parameter in to the decorated implementation and the fallback value was given instead.
The caller expected the method to do something and did not branch into an alternative way but the default value disables the expected behaviour. Eventually nothing happened.
Breaking changes in patch levels woop di fucking do.2
My manager asks, in Slack, if we can change the auto-tagger to update the patch instead of the minor version. I respond by saying, "Yes, it's in the Jenkisfile. Really we should switch to just <major.minor> and drop patch."
My manager asks why and I go on to say the last number is useless (unless you ship software externally and need to hotfix or security patch a minor release; internally they serve little purpose).
At my last job we dropped three numbers for two, and most other teams here only use two numbers.
He sends a link to the semantic versioning website.
The next day one of the other developers sends it to me in a private chat as a joke. 😂😅 I'm glad I'm not the only one who thinks our manager shouldn't be a manager.
npm has to be the single worst package manager on the planet... Trusting devs to use semantic versioning properly and forcing devs to trust authors of dependencies to use it properly is nothing short of insane. The package-lock that is "supposed to be version controlled" causes *constant* merge conflicts. Using shrinkwrap in its place is borderline useless because it Doesn't. Lock. High. Level. Dependencies.
I don't know who designed this, but I want to give them a very bad day for every hour I've spent trying to lock versions correctly on a live project.
Not to mention requiring root by default to install things that can just run whatever they want is ludicrous.2
Hello, I am doing master in Pharmacy, but I like programming and consider to switch or connect somehow industries. I could write simple scripts and small programmes in Python, but I want to write code with good practice from beginning.
So my question what should I know and put in use, maybe some resources if someone has them or just terms for further search. At this moment I use gitlab for VCS (my commits sucks and my whole usage of Git sucks, but at least I use branches), I am trying to separate control from model (MVC but I guess I do it poorly), also I use keepchangelog rules for changeling, and semantic versioning for versions, PEP8 and Pokemon names for my variables and functions as it helps read code later.7
This guy nails it!
A talk about (semantic) versioning and breaking updates which make you spend countless hours to just adapt to a new library upgrade and how we can do it with a bit less PITA.
tl;dw: The answer is codemods.
What's your routine for versioning pre-releases?
While working on a big change, like "milestone 2.0", how do you, while working on it, version it before the main release? To keep it being 2.0.0 on release and not for example 2.130.0 (since it was "2.130.0-pre" just before release)?
Or is it my fantasy that when released to public it "should" always be *.0.0?1