A minor version bump (new features) **should be** more interesting than a major version bump (breaking changes). v2.4.0 -> Super cool new capability! v3.0.0 -> Drop Node.js 16 v3.1.0 -> Another cool feature! - ThreadSky

antfu.me • 45 days ago

A minor version bump (new features) **should be** more interesting than a major version bump (breaking changes).

v2.4.0 -> Super cool new capability!
v3.0.0 -> Drop Node.js 16
v3.1.0 -> Another cool feature!

Comments

scheppening.com•45 days ago

Surprised how much sense that makes.
Is it fair to assume that it could be grouped as v{any breaking-change}.{feature}.{refactor|bugfix|chore} ?

scheppening.com•45 days ago

Okay realised how rhetoric the question is looking at the fact that bumping packages use conventional commit with their type for exactly that.

haoqun.dev•45 days ago

To amplify the message maybe we can add codenames to minor releases, while attach nothing to the major ones, so that only the minor releases are cool?

nullvoxpopuli.com•45 days ago

Ye! Looks like this is what ember does!

https://bsky.app/profile/patak.dev/post/3lfowiv6o5k2g

samalrasmussen.bsky.social•45 days ago

*should*

Semver would be great, if it wasn't for the users of it. As is, you can't trust that anyone who says they do Semver actually does it right every time. And when updating one dependency you end up updating maybe hundreds of dependency dependencies and someone is bound too have messed up.

nullvoxpopuli.com•45 days ago

All the more reason to have a good package manager (not yarn@1)

Deep dep updates are truely private.

Agree that some people still mess it ep tho. Facing this now with lru-cache floating to another major, which dropped node 18 (only when using yarn@1 tho?!)

sandros94.com•40 days ago

My personal reactions to semver are:

patch -> "yes! maybe that issue has been fixed!"
minor -> is like receiving a gift from someone who knows you
major -> is like receiving a gift from a random person

patak.dev•45 days ago

I think you'd like how @emberjs.com uses semver:
> Ember major versions only remove deprecated features. They never introduce new features. This means major releases are not exciting, just a predictable point where some cleanup happens.

patak.dev•41 days ago

Better to read about Ember's strategy from Yehuda if you get to these threads ❤️

patak.dev•41 days ago

And more here

patak.dev•45 days ago

> We never couple the addition of new features to breaking changes. Instead, we introduce a new feature to replace an existing feature, provide a migration path, then sometime later deprecate the old feature, and finally remove the old feature in a later major release.

sandros94.com•40 days ago

I wonder how I should couple this with smaller projects. When a complete, breaking, refactor needs to take place.
Most importantly because I tend to over engineer things...

But indeed Ember has a really nice approach

antfu.me•45 days ago

Yeah 💯, that's precisely how a good release should be in my mind. Just that the current versioning system is counter-intuitive, so we have to fight with it :P

patak.dev•45 days ago

cleanup.features.fixes

fvsch.com•45 days ago

i don't think we'll ever find a good pattern as long as we try to make one version number account for:

1. tracking new features
2. tracking API stability
3. tracking changes in side-effects (e.g. for compilers and linters; see the eternal "typescript doesn't follow semver" controversy)

fvsch.com•45 days ago

Those are 3 different concerns with almost no relation to each other. Giving them a hierarchical structure like major.minor.patch cannot make logical sense. :P

patak.dev•45 days ago

Ember Editions made me think of Semver epochs, even if they don't attack the same issue. It's so interesting that they do editions in minors. They really are all in with their semver strategy.

innocenzi.dev•45 days ago

I prefer this over semver epochs, because majors version numbers won't feel completely overwhelming with time

I really like what Ember is doing and might even adopt this in my own projects

Comments

Posting Rules

Reply