Hacker News Reader

Comment by kall | Hacker News Reader

Seeing a project on a pretty high major is a positive signal to me. It tells me that they understand semver and know how to use breaking changes. Of course if a project is just very stable and sticks to 1.x, that‘s great too. I don‘t consider that a negative signal. Purely anecdotally, 3 is the scariest version number to me.

React sets a pretty good example here: react 17 is the most boring release in the world. The react team are not bad API designers that made 17 major mistakes. They may be the most considerate and pleasant API designers in all of frontend, actually.

React Native is on 0.64.4 (?) not because it‘s unfit for production but because they know the level of guarantees they can make about version upgrades is zero.

View on HN

To me it's a signal that if I rely on this software in my own projects, I am signing up for an upgrade treadmill.

Amen.

I've also seen projects on like 124.0.0 just because they don't care about semver and just release major versions every time.

Still a better release numbering scheme than going by year and update.

The Naval Research Lab releases their radar processing algorithms package for geointelligence products by build number. We always got a kick out of a new delivery updating us from nrltools-3872 to nrltools-4923 or something.

It's also easy to get to 124 if you are a library with very few private functions -- in that case almost any change breaks ABI.

2 seems to be the final number for business stuff. CustomerReportv2 or UserModel2 or /api/v2/ are wildly more common than 3 IME.

“That major update where we redid the whole API turned out to be so unexpected painful, we’re never doing that again” once for every business

I think it goes something like

1: We made something that we think is good, but we don‘t know if others will and how they will use it. We tested it well in one scenario but not much else.

2. Now we actually understand how people use this and why they like it. We have collected all of their biggest problems and it‘s time to fix them.

3. Everyone loves our thing and it‘s very productive for them. That must mean we‘re geniuses. Let‘s fuck around and change the world.

4, 5, 6… Both we and our users understand that sometimes we need to make a breaking change. They already went through the terrible 2->3 migration so every other upgrade will be fine by comparison.

In an enterprise context there are probably enough layers that keep everyone in check so the step 3 where you run wild with your ideas never happens.

yes but didn't react do a big jump? like 0.13 -> 14.0 or such many moons ago. at any rate agree with the point

0.x releases are also major versions according to semver, just pre-stable. So many people were referring to React 0.x releases as "React x" that they just bumped it straight to version x.

Unfortunately, go has broken semver, so all of my go projects now stay at 1.x.y, with x being the "major" version (breaking changes) and y being the "minor" version (non-breaking changes) and the 1 sitting there useless. I suspect that many others do the same, so for go projects the x version field is the one to pay attention to.

Although TBH it's not all bad; all anybody has ever really cared about is "are there breaking changes or not?"

Reply on news.ycombinator.com