COVID variants should adopt a semantic versioning, rather than using greek alphabetics.
COVID v.19.2.34
COVID V.22.1 Beta (testing in US)
COVID v.22 release 1 (being tested somewhere in London)
COVID v.22 nightly builds (still brewing in China)

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 😧

Why is it that pretty much zero package & framework maintainers understand semantic versioning?

1. If you do a complete rewrite of your package, but the resulting API is identical, you don't need to bump to the next major version. As a user, I'm thankful for your increased performance or cleaner internal code, but it doesn't really affect my update process.

2. If your package required some-framework 6.0.0, and now ALSO supports some-framework 7.0.0 but is still compatible with 6.0.0, you don't need to bump to the next major version. As a user, I can now upgrade the framework, and know that the package will keep working, but otherwise it doesn't really affect me.

3. Following your versioning along with the framework/language version is super annoying, especially if your library really doesn't need to differentiate between framework versions because it's not actually utilizing new framework functionality.

4. On the other hand, if you stop supporting a certain language, framework or shared library version, or change the public methods, exceptions, fields, etc, you MUST bump to a new major version.

Yet everyone gets this wrong.

For example, many of Laravel's underlying subpackages (for collections, filesystem, database, config, http, mail, etc) do not change their code in a breaking way, or do not even change at all between major framework versions.

Yet they follow along with the major framework version.

Now if someone makes a library "laravel-elasticsearch" which uses the support libraries and collections from laravel, they need to update their package to move along with the versions as well, and often they choose to number their library along with the framework in turn.

This means that to update the framework, you also need to update over 9000 dependencies.

FOR NO FUCKING REASON. THE ONLY CHANGE IN THOSE FUCKING DEPENDENCIES IS TO UPDATE COMPOSER.JSON TO BE COMPATIBLE WITH THE FUCKING FRAMEWORK.

Meanwhile, Laravel itself breaks repeatedly on minor/patch version updates, because breaking changes slip through their review process.

Ugh.

hey google, make my life harder. let's have an SDK version, then a corresponding android version, and finally a clown name like cotton candy or oreo or whatever so I always know exactly what version I'm working with without confusion 🙄🤡

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.

Working on another SaaS product, and now I've run into a "fun" conundrum that is hard to determine cleanly in an automated fashion.

I'm certain it's stupid bullshit opinionated conventions like this as to why so many devs are driven to burnout and bitterness...

Semantic what?

"mmx-a00112-bwt-1.6.2e_dirtyPatch_withoutCityTours_startpageHack_2.zip"

I just "had to" send a tutorial on semantic versioning to my boss the other day. he was like, wait, i thought we were further along than 1.1.1, didn't we release 1.0.11 before?

idiot.

Mojang/ Microsoft no longer understands semantic versioning??

They released a new update for Minecraft, 1.21.5 - but it:

- Adds new features
- Breaks backwards compatibility

Look at this. The left side of the screen was generated in 1.21.5, the right side was in 1.21.4 You can literally see the split down the middle where the trees generate differently because of the update.

This doesn't *matter* but it's just bothersome to me! Fuck you! I'll rant about whatever, no matter how small!

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.

Who here uses Semantic Versioning as the version protocol, and if not, what do you use?

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.

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.

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?