Why Semver is Wrong?

Before we discuss Semver, we should look at what is the version.

Version

If we ask, we can get these meanings:

1. a particular form of something differing in certain respects from an earlier form or other forms of the same type of thing.
2. an account of a matter from a particular person's point of view.

For software development, meaning 1 is more fit.

So when we talk about versions in software development, it means differences.

Kinds of versions

We now know that versions are here showing differences.

But what kind of versions do we need to be shown in software development?

There are at lease three kinds of versions we need to look at:

1. source code versions
2. build and/or release versions
3. product versions.

Each versions differs in their frequencies. Normally, they change to meet different events,

1. Source code versions changes when every commit is made.
2. Build/release versions change when more commits are made and tested to make consistent software.
3. Product versions change when a lot of small builds and / or releases are made to make products have a upgrade.

Why Semver is not right?

Semver in other hand mixes them together or at lease mixed bulid/release verions with product versions which makes it neither semantic nor correct.

It makes major, minor, patch version meanless.

In fact major, minor, patch perfectly make themselves the product version, which is used to indicate product version changes like upgrade, features and fixes.

It has nothing to do with api consistency. But how do we keep api consistency?

API consistency has nothing to do with versions.

The API Consistency is another area in software development. It is a problem of software design / architecture.

We don't need to change apis even if products moved to a new level. For example, Unix posix apis haven't changed so far, even Linux/Unix is going so far with Graphic UI and more powerful hardwares supported.

If someone designed apis with big changes just means they are of low level in designing system apis, it has nothing to do with versions.

Chaos introduced by Semver

Semver is introduced by node.js' package management. It advocates that packages should keep none breakable on minor versions and should auto update to new software versions of dependent packages to keep package updated to the newest non broken version which is called green keeping and makes it a dependency hole.

This misleading causes npm useless for desktop / server side programming which needs high stability.

Semver makes software version meaningless by upgrading them for every broken change which is the designing problem.

Conclusion

Semver is misleading in so long time, I hope I can make versions clearer than mix them up and bearing design/architecture burden.

As we have been bombed with so many wrong ideas, we should be cautious to accept any new idea which may be proved wrong.