Hacker News Reader

Comment by transfire | Hacker News Reader

In my usage of SemiVer I felt it lacked what I call a "gestalt number" which would be the first number, representing broad changes to the design which (almost always) necessarily include API changes. But API changes can happen within the same "gestalt".

View on HN

One option is to move the "gestalt number" into the name. It's more common in end user software than APIs since it's more of a marketing thing. Like Mac OS X, Windows 10, Sublime Text 3. It doesn't have to be a number either, like Photoshop CC.

I've certainly encountered this issue.

When I release ConceptNet, I would like to follow SemVer, but it kind of has to be in a way that the second component of the version is the major version, because there are bigger things that happen in a multi-decade project than just API changes.

The project is ConceptNet 5. It is the fifth project named ConceptNet. What it has in common with ConceptNet 4 is some of the data and the spirit of the problem to be solved; the design is quite different.

It's on the sixth major version after the initial release, so I call it ConceptNet 5.6. The current version is 5.6.4. If I wanted to use tools that expect SemVer, I'd have to call it something like "ConceptNet 5 v6.4". I find that confusing, and I think other people would too.

Why does a SemVer spec have to deal with that? Why not have a "gestalt" number/indicator for purely informal use, but keep the SemVer part as is?

And call the project Foo 3 v4.1.9? That seems pretty confusing.

That's essentially a 4-part version number. For most projects it's over the top and almost no-one used or uses 1.2.3.4 version numbers. I've seen libraries use "library3 1.6.2" [1] but it feels very strange and confusing.

[1] https://github.com/etorreborre/specs2/releases

Yes, that is my biggest problem with semver too. Will upgrading 15.1.2 to 16.0.0 be a big upgrade? It could be a single function changing it's signature or a whole different API.

It also encourages version bloat. Previously a 2.8.0 upgrade to 3.0.0 meant a big change. Now you just see versions 1 through 40 with very little usage of minor version numbers.

I don't know of a good way to fix it. At least semver is something everyone more or less agrees on.

I don't get the issue with large major versions. That just means that instead of holding a change for a looong time until it was "acceptable" to create a new breaking version, they released the changes asap for developers to take advantage of, and clearly communicated each time that there was something you'd need to take care of.

For developers who would wait that long anyways, there's no difference between moving from 2.x.x to 40.x.x over 2 year's time than 2.x.x to 3.x.x over the same time period. (Edit to add: except that if you more regularly upgraded versions between 2.x.x and 40.x.x, you don't wind up with needing to make a huge amount of changes in one go from 2.x.x to 3.x.x.)

It's a big question of "am I comfortable updating" when you see a major version increase. If a project is doing a major version update every month, in my mind that's probably not a well designed project, the developers really didn't think their API through, and it's a huge risk to my business trying to integrate that into my product. Every month I'm going to have potentially breaking changes that will suck down developer time.

For projects like Rails, where they optimize for developer productivity, it's good that we've only had 5 versions in 13 years. It's a stable platform to base a business from. When I see projects like React where they've released 16 major versions in 5 years, as a small developer that is a huge risk to take. There should not be that many breaking changes if the project was well thought out from the start, and I can't spend that much time fixing everything that breaks every few months. And if the project was so poorly conceived that it needs 16 major versions in 5 years, there's probably a lot of broken stuff in version 15 that I need to update to version 16 to fix, so I can't just stick with the older version.

On the other hand, I feel Python waited way too long between 2.0 and 3.0 and introduced too many changes all at once, leading to the headache of so many people still using 2.x more than 10 years after the release of 3.0.

> When I see projects like React where they've released 16 major versions in 5 years

They haven't really, they just jumped from 0.14 to v15, because people were referring to 0.x releases as "version x". v15 is basically v1.x and v16 is v2.x

But that's the benefit of semver (or romver like other people have mentioned). It takes the guesswork out of it.

Also can we talk about the silly trend of publicly released software used by thousands or millions of people on production apps and they haven't made it to version 1.0 yet? 0.x is for unreleased software. If you've released it to the public, it's 1.x. As a small developer that's another huge red flag... functionally there is no difference between 0.15 and 15.0. They both indicate poorly conceived projects where the version numbers mean absolutely nothing and there's no guarantee that it will work tomorrow.

And I say that as someone who uses React, I'm not just hating on it from the outside. I'm seriously terrified by the version numbers.

The biggest problem is with an ecosystem of libraries. I avoid libraries that depend on Google's Guava because one uses 21, another 24, another 23.5. There will maybe be a year between 21 and 25. All binary incompatible.

So you either need to stick to 1 version for the whole ecosystem or use tricks to give each library its own exact version of Guava it expects.

That seems like a problem with Java or Maven: it doesn't allow multiple major versions of a library to co-exist within a project. NPM and I believe Cargo both allow this. There's cases where this isn't great (where multiple libraries each need to communicate with each other using a data structure implemented by another library, but they each depend on a different version of the data structure library, or where the library you have multiple versions of is gigantic; this might be a good argument for using many small and focused libraries instead of fewer big ones), but overall allowing multiple versions in one project can save a lot of needless headaches.

The NPM approach does not have that specific downside indeed, but like you said. What are you going to do when both return a different version of a Type to the "main" code?

It's not a Java/Maven problem. Rubygems, Pip and Cabal have the same restriction, and that's only the ones I know that have it.

openssl kind of works like that -- but I believe they are moving to semver

Reply on news.ycombinator.com