Hacker News Reader

Comment by tolmasky | Hacker News Reader

The absolute most important thing they could do is add a fourth number, at the front, that is meaningless - the vanity number. vanity.major.minor.patch. There has been so much wasted time, and incorrect versioning, just because people have not "felt" that breaking changes constituted "major" semver updates - just to then break many production systems due to semver ranges only working iff major, minor, and patch actually attempt to mean anything.

This is a losing battle -- we are never going to convince people of this. So let's just acquiesce. Let's allow the first number to advance at whatever rate you like. It's the "human" portion of the version number. That way, everything to the right of it, no one will care about and can serve its actual purpose. Ultimately this isn't even a new idea, its just "the PR version" vs. "the build number" just like native apps have had for ages.

View on HN

Not sure if it's a good idea.

A better idea in my opinion would be to have 2 versions:

* an "API" version that specifies technical changes.

* a public version more representative of big milestones in the project.

It's roughly what is done in the C/C++ ecosystem with sonames.

But I agree, that's indeed a flaw of SemVer IMHO. According SemVer, even if you are adding tons of new cool and useful features, while maintaining compatibility of existing one, you are not supposed to increase the major number.

From a "social" point of view, it gives the feeling a project is not really active.

And even from a technical perspective, bumping the major in case of significant changes can actually be a good idea. When I see an X.0.0 release, I kind of expect major changes inside the project, and even if the project remains compatible, significant changes generally bring bugs and instability, in some context it might be a good idea to wait for a version like X.1.4 to remain stable.

With semver, 1.42.0 -> 1.43.0 can be a small add on of one method or tons of new methods. And even 1.2.2 -> 1.2.3 can be an entire rework of the internals, while the API stays exactly the same.

Don't get me wrong, SemVer is great, it has enabled far less painful dependency management and better tooling, but some human and qualitative aspects are lacking in this versioning scheme.

There's no difference between our two ideas except that I have put both "versions" together in one string (please correct me if I'm wrong here).

The reason I've done this is because the second you make one version the "real" version that developers will see in their config files, that number will once again take on "emotional" value and lead to resistance to updating it.

There is theoretically nothing stopping node developers from using the system you describe today -- except that the "API" version is the one that people see in their files, and so naturally becomes the "spoken" version. If the "public version" isn't represented anywhere meaningful, then it requires a tremendous amount of 1) work on the developer's part to communicate its existence, and 2) restraint to maintain the spirit of the semver that users will actually repeatedly see. This is certainly something that a big corporation like Google is capable of, but small package developers in the ecosystem have shown that they are unwilling to do. The simple hack is to just append the "public version" to the front of the "API" version, and now everyone is happy.

I can't find any reference to not being able to increment the major version if you maintain compatibility. Only the reverse is specified, you must increment it if it is broken. https://semver.org/#spec-item-8

I'd think the problem with bumping the version number if you're remaining compatible is that it signals to the end-user that you're not compatible. i.e. when I start using 2.x the constraints I'll put in my list of libraries is < 3.0 (because otherwise my project could randomly break upon 3.0's release, depending on whether it's compatible or not).

The issue with the present system is that we have one numbering scheme trying to satisfy two very different roles:

- automated dependency management (“can I safely update to this version?”)

- marketing (“do I care about this new version?”)

I’m running into this issue with “prettier”, a JavaScript pretty printer. If we were to follow semver, we’d have to always bump the major version because every version changes in some way or form the output of some construct.

Instead what we opted to do is to have the major be 1. to signify that the project is mature, the minor for roughly quarterly big updates and the patch for hotfixes right after we ship a new update.

But at that point what you're doing has no resemblance to semver. And there is nothing at all wrong with that!

Just don't call it semver, because if you do, people will expect it to be... y'know... semver.

The same applies to putting your not-semver version number into places where people or tools expect a semver number to be placed. If you encounter those places (like npm) please put an actually-semver number in them.

I don’t call it semver, I publish it to npm with this version number.

The fact that npm install automatically adds a ^ next to the version number has caused so many issues in the past where some deep dependency would push a patch, not following semver, and break a huge part of the end users.

Thankfully, yarn lockfiles were introduced and solved the problem. Only people adding the dependency for the first time would see the new behavior, which is usually fine.

Looking at the definition from Steve's post:

> For this system to work, you first need to declare a public API. ... Once you identify your public API, you communicate changes to it with specific increments to your version number.

If you don't have a public API in Prettier, SemVer doesn't actually apply. If you do have a public API, only changes to that API (meaning the types, arities, functions, names, modules etc.) qualify for version number bumps. Everything else (like changing the output format) does not qualify.

I’m no expert in semver, but I’m fairly confident that updates which change outputs absolutely count as breaking changes. Surely it isn’t just the signatures of public APIs that are considered to be breaking changes.

It seems to me that the semver concept of “breaking changes” by definition applies to almost all changes to a code formatted like Prettier, except for updates which truly don’t affect the output of any given input (like performance improvements or support for additional platforms).

Most pieces of software can have non-breaking changes like adding new features, but if you add a new feature to Prettier (like specific formatting rules for React hooks [0]), you of course change the formatted output of code that uses React hooks.

https://github.com/prettier/prettier/blob/master/CHANGELOG.m...

It's as simple as adding to the README 'do not depend on specific output as it will change between versions' and then you're doing server...

Well, sure, you could always just lie. But in practice, Prettier updates would literally be breaking changes, as in, if you have your CI verifying that code conforms to Prettier's formatting, and you're using a new version of Prettier locally, your commits will literally break the tests. Which is, of course, what "breaking change" means in practice.

Looking at the actual specification ( https://semver.org/ ):

> 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

I don't believe we can make such a claim about Prettier's output format. For example, how would you denote a backward-compatible change to the output format?

Prettier has a clear API.

That’s my point: there by definition cannot be backwards-compatible changes to the output format.

> there by definition cannot be backwards-compatible changes to the output format.

In that case we can conclude that it's incompatible with SemVer! SemVer is all about trying to convey what changes to a package are backward-compatible and thus are safe to upgrade to new versions. The whole point is that you can say something like "that-package": "^3.9.1" and mean that you're OK to upgrade up to anything less than 4.0.0. If you can never do that, the package is obviously not using SemVer.

Since prettier isn't using Semver (I don't think it can either), maybe instead of Semver, you can experiment with alternate schemes which do provide more clarity. Example: an `YYMM.patch` style version, something like "1903.01"

I'm kind of convinced that this is one of those times where doing anything is worse than doing nothing.

Do we really have a real problem here deserving of all the costs that come with more change?

Exactly. Leave what works. The emperor doesn't need new clothes and we don't need the pain of fashionable, consumerist, job-security churn.

In the case of a non-breaking "new version" release would you go directly from, say, 1.4.6.0 to 2.4.7.0 then?

And for a breaking "update" release you' go from 1.4.6.0 to 1.5.0.0?

Yes, precisely. You could have big flashy releases with "2" branding that as far as automatic updates are concerned are non-breaking and non-conceptual (new logo! we got acquired! better docs! whatever). You can also have important bug fixes that will break existing clients and thus should not auto-update, but under the "idea" of 1.0.

That sounds awful. It makes it even harder to make decisions about whether to accept a new version because it is tangling different concerns into a single knot and saying "here, we might mean all of these things, you figure it out!"

Just change the name.

The name doesn't show up anywhere

Also, there is too much focus on the least important of the two scenarios: wanting to increase the version number with no meaningful changes. The actually important scenario is the opposite: when the major version SHOULD be upgraded but people don't want to give the impression that this is a "major release" (in the colloquial sense). This is why the name is irrelevant: this is a situation where you'd want to "keep the name the same", and we already see that not working.

Perhaps you'd be happy with making the vanity portion I suggested a "name"? mojave.1.0.3? This is 100% equivalent to what I was already proposing (the vanity section is pure vanity and is meaningless in package resolution), but seems to also satisfy your concern that it would be confusing if it were a number. Does that satisfy your concerns? My concern is simple: unless he "name" shows up in config files, it will not have the power of the "major" version and will thus inevitably result in people not properly upgrading the major version when necessary.

Honestly, I agree with you.

A current client has been trying to dictate our version numbers purely for marketing purposes and we've been pushing back since the start of the project. They originally wanted us to release 1.0 as 1.5, literally so they could imply that the software was further along than it actually was at the time (software marketing people sure seem to love lying to their own potential clients).

At least we no longer tie our sprints to version numbers (also at the behest of the client). Our scrum master eventually decoupled them unilaterally because the workload was getting ridiculous, and our internal project management was ending up as simply a formality because of it. We're all grateful for that one.

Clients don't always help themselves here though with blanket policies against deploying 1.x or x.0 releases.

> Let's allow the first number to advance at whatever rate you like

This is what I feel like Pip did. https://pip.pypa.io/en/stable/news/

it went from 1.5.6 to 6.0, and later from 10.0.1 to 18.0.

Ok.

I don't know anything about the 1 -> 6 jump, but the jump to 18 was because they switched to time-based versioning last year (2018). First release of 2019 was 19.0.

the 1 -> 6 jump was because they decided to drop the first number. Yes, they had reasons, but changing version schemas twice in a couple years is a great way to confuse people in the interest of just doing whatever the author likes.

This is called explicit versioning [1].

But in my opinion the correct fix is the one suggested in this comment: https://news.ycombinator.com/item?id=19138143

Windows is a great example: the number behind the name (7, 8, 8.1, 10, etc.) is just marketing gobbledygook. It doesn't even have to be a number (XP, etc.). The real version number of Windows is hidden from regular users---though they don't follow semver so I'm not sure it has much value per se. But they could plausibly adopt semver and regular users wouldn't need to know.

Let the marketing people choose the branding and the developers choose the version numbers. Keep those concerns separate, don't force them to be conflated.

[1]: https://medium.com/sapioit/why-having-3-numbers-in-the-versi...

Yea I don't get why you can't do this already, effectively. Just hide the real semver in the place it'll be consumed, with a comment tying it to the branded version if you want to reduce confusion.

By numbers NPM is probably the biggest ecosystem using semver but the config files are JSON which don’t allow comments. Bit of a PITA generally but also makes this tougher to do consistently.

A somewhat off-the-wall solution to this problem would be to require major versions to start at some arbitrary lower limit much greater than 1. For example, imagine every semantic version started at 123.0.0. It's less of a big deal to go from version 123 to 124 than it is to go from 1 to 2.

I recently learned that a system like this is already described by Haskell’s Package Version Policy[1]. They call the vanity digit the “epoch”[2]. Basically the way the formalize it is that the first two components specify the major component, and a breaking change must correspond to an increment where the new major version is lexicographically greater than before. Depending on the whim of the maintainer this can be by incrementing the first or second number.

[1] https://pvp.haskell.org [2] https://pvp.haskell.org/faq/#semver

I don't see anything wrong with something like "Angular 2 (v1.3.6-a)".

It's not a new version of the same software -- it's new software.

Just to clarify, the real concern is the opposite of what you are showing, when the semver version advances faster than the "desired" version. So for example, something like Angular 1 (v2.5.6), because it contains a change that breaks 1.x.x users.

Regardless, "what's wrong" is that people just don't behave this way, and there's no way to convince them otherwise. For better or worse, semvers have taken on the dual role of "build version" and "public facing version" (probably because that's the only version users actually end up seeing out in the wild). So there is tremendous resistance to advancing the MAJOR portion of the semver faster than their "marketing" desires. I have been in many, many, frustrating arguments on GitHub where there are several users that are begging to simply release a package under a MAJOR update instead of (erroneously) under a MINOR version, because it is incredibly difficult and confusing when a subdependency of a subdependency picks up a seemingly innocuous change which is actually breaking solely because "it still felt like it belonged in this major version", and the "fix" for this on the user's end is super complex - having to dive many layers deep in the dependency tree and wrestle with a lockfile - all because the change "didn't feel 2.0 worthy".

In theory, if you can prove that a change breaks current users, there should be no further discussion, the change merits a major update. But you will be surprised how all of a sudden crazy unrelated arguments start popping up. Ultimately, its all because there is an emotional attachment to the leftmost number, simple as that. Look no further than Underscore's "romantic versioning" (https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e ) drama back when SemVer was first introduced, when it was stated that it would be ridiculous for underscore to be at "version 157" or something had they followed semver to the letter. But again, its only ridiculous because people want to attach PR value to the Major version. It is absolutely not ridiculous from the perspective of knowing that there were 157 breaking changes, and 157.x.y won't work with 156.x.y.

Great idea, but for political purposes, you might not want to call the first position 'vanity'. Perhaps 'symbolic' or 'headline'. (Or even, 'political'.)

No, call it vanity.

People deserve to be reminded that the entire thing is silly ego. Every single time.

But then they'll take it on their ego, thus defeating the purpose

Lecturing people that their preferred "leading version number" practices are "silly ego" won't help this better system attract support.

But also, it's false. It's a legitimate convention, across a bunch of domains that are either analogous or intersecting with software-development, to use increments of the 1st number to signal "big user-meaningful changes" (as opposed to exactly-and-only "interface breaking changes"). It's not just ego, but evolved communication.

That's what Haskell has done for a while now! https://pvp.haskell.org/

Hard disagree here. The tides are finally starting to shift on this and customers are demanding it -- no need to capitulate now.

Your version number is an IP address. Among the many problems that can occur, like leaving out --ppapi-flash-version= or putting a space after it:

  exec /usr/bin/chromium --ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so --ppapi-flash-version=$(grep version /usr/lib/adobe-flashplugin/manifest.json | cut -d '"' -f 4) "$@"

If it is for vanity then as another comment suggested include it in the name:

  python3 --version

1.1 and 1.1.1 are also valid IP addresses (and http://1.1 even works as a URL) via an obscure shorthand notation. Valid to `inet_aton()` at least, but definitely more recognizable as a version than an IP to humans.

Reply on news.ycombinator.com