[GH-ISSUE #365] why minor versions can't make incompatible changes? #1138

New Issue

GiteaMirror · 2026-04-16T10:23:57-05:00

GiteaMirror commented

2026-04-16 10:23:57 -05:00

Originally created by @calidion on GitHub (Apr 17, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/365

Does this mean, angular 4.0 or any other versioned software can not change any api or function during their development?

it is obviously not true.

both major and minor version should be able to make incompatible apis.

major versions often lead to arhitectural change or upgrade, while minor versions lead to api changes.

the problem is not we change apis in minor versions but packages should not auto upgrading its dependencies to newer versions.

auto upgrading is the reason that causes all problems not versioning.

I do repect the api stability of the all packages, but I think it should not be mandanary.

I think major or minor versions should be free to make incompatible apis while respect the stability of package apis.

Originally created by @calidion on GitHub (Apr 17, 2017). Original GitHub issue: https://github.com/semver/semver/issues/365 Does this mean, angular 4.0 or any other versioned software can not change any api or function during their development? it is obviously not true. both major and minor version should be able to make incompatible apis. major versions often lead to arhitectural change or upgrade, while minor versions lead to api changes. the problem is not we change apis in minor versions but packages should not auto upgrading its dependencies to newer versions. auto upgrading is the reason that causes all problems not versioning. I do repect the api stability of the all packages, but I think it should not be mandanary. I think major or minor versions should be free to make incompatible apis while respect the stability of package apis.

GiteaMirror closed this issue

2026-04-16 10:23:57 -05:00

GiteaMirror commented

2026-04-16 10:23:59 -05:00

@vearutop commented on GitHub (Apr 18, 2017):

If minor version can introduce a breaking change, it means for every minor upgrade a developer should make sure that nothing is broken, often this may require much effort.

This is the purpose of Semantic Versioning:

minor upgrade is effortless,
major upgrades should be rare.

@vearutop commented on GitHub (Apr 18, 2017): If minor version can introduce a breaking change, it means for every minor upgrade a developer should make sure that nothing is broken, often this may require much effort. This is the purpose of Semantic Versioning: * minor upgrade is effortless, * major upgrades should be rare.

GiteaMirror commented

2026-04-16 10:23:59 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@vearutop

the problem is that semver / npm assumes that every package shoulde auto upgrade minor versions, not that minor versions change their apis.

minor changes or upgrades often lead to api changes and it is inevitable.
but it is unnecessary to upgrade the major version, because these are only minor changes due to some small feature requests or bug fixes or deeper understanding.

the idea on

minor upgrade is effortless

is in effect wrong and a misleading of the process of the software developement, which leads to constantly major upgrades which is on the contrary to the idea you bear:

major upgrades should be rare.

so the idea is self contradictory because of the wrong assumption that minor version should be effortless.

currently most node packages are unstable due to the false assumption that minor versions should be effortless and that seems to be a cause for yarn being introduced which use the accurate and exact version for every package installed.

so I think the wrong assumption is the false root for npm and semver.

the very simple way to correct the false is:

npm assumes no auto upgrade
mannuly upgrade all package versions
make no assumption that minor version changes break no apis.
enable multiple versions installation for a package.

@calidion commented on GitHub (Apr 18, 2017): @vearutop the problem is that semver / npm assumes that every package shoulde auto upgrade minor versions, not that minor versions change their apis. minor changes or upgrades often lead to api changes and it is inevitable. but it is unnecessary to upgrade the major version, because these are only minor changes due to some small feature requests or bug fixes or deeper understanding. the idea on * minor upgrade is effortless is in effect wrong and a misleading of the process of the software developement, which leads to constantly major upgrades which is on the contrary to the idea you bear: * major upgrades should be rare. so the idea is self contradictory because of the wrong assumption that minor version should be effortless. currently most node packages are unstable due to the false assumption that minor versions should be effortless and that seems to be a cause for yarn being introduced which use the accurate and exact version for every package installed. so I think the wrong assumption is the false root for npm and semver. the very simple way to correct the false is: 1. npm assumes no auto upgrade 2. mannuly upgrade all package versions 3. make no assumption that minor version changes break no apis. 4. enable multiple versions installation for a package.

GiteaMirror commented

2026-04-16 10:24:00 -05:00

@vearutop commented on GitHub (Apr 18, 2017):

npm uses version constraints to resolve dependencies, same as most dependency managers for other languages. If you want to stick to a particular minor version you can use ~ tilde constraint.

minor changes or upgrades often lead to api changes and it is inevitable.

This is just a semver violation, there is no semver fault in that.

currently most node packages are unstable due to the false assumption that minor versions should be effortless and that seems to be a cause for yarn being introduced which use the accurate and exact version for every package installed.

Same as above, if the package can not reach stable versioning it is about package, not semver.

@vearutop commented on GitHub (Apr 18, 2017): `npm` uses version constraints to resolve dependencies, same as most dependency managers for other languages. If you want to stick to a particular minor version you can use `~` [tilde constraint](https://docs.npmjs.com/misc/semver#tilde-ranges-123-12-1). > minor changes or upgrades often lead to api changes and it is inevitable. This is just a semver violation, there is no semver fault in that. >currently most node packages are unstable due to the false assumption that minor versions should be effortless and that seems to be a cause for yarn being introduced which use the accurate and exact version for every package installed. Same as above, if the package can not reach stable versioning it is about package, not semver.

GiteaMirror commented

2026-04-16 10:24:00 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@jeme @vearutop

why some of them is not able to adhere to or violate SEMVER?

Because people make mistakes.

semver is too optimistic about human being which makes it unreasonable for a real versioning which is published by human beings who is apt to make mistakes.

as for the example you illustrated, i think we are not misunderstood.

apis can be chaged to due to upgrade, but also can be changed due to previous misunderstanding or mistaken, there is no reason that minor versions should keep their compatibility.

Why I mentioned npm is that npm's versioning system is based on semver, which has causing a lot of problems which you have mentioned mainly on its stablity and reliablity which is due to the false assumption that minor versions should be compatible.

I think semver is a good example on the progress of how to do the version managment, but not that matured at present, it seems too restrict, and the versioning of software is more of technology and engineering than of science.

@calidion commented on GitHub (Apr 18, 2017): @jeme @vearutop why some of them is not able to adhere to or violate SEMVER? Because people make mistakes. semver is too optimistic about human being which makes it unreasonable for a real versioning which is published by human beings who is apt to make mistakes. as for the example you illustrated, i think we are not misunderstood. apis can be chaged to due to upgrade, but also can be changed due to previous misunderstanding or mistaken, there is no reason that minor versions should keep their compatibility. Why I mentioned npm is that npm's versioning system is based on semver, which has causing a lot of problems which you have mentioned mainly on its stablity and reliablity which is due to the false assumption that minor versions should be compatible. I think semver is a good example on the progress of how to do the version managment, but not that matured at present, it seems too restrict, and the versioning of software is more of technology and engineering than of science.

GiteaMirror commented

2026-04-16 10:24:00 -05:00

@calidion commented on GitHub (Apr 18, 2017):

consider such a situation :

// v1.1.0
function fetch(url, cb) {
}
// v1.2.0
function fetch(url, options, cb) {
}
// v1.3.0
function async fetch(url, options) {
}

the purpose of fetch is not changed, but the paramters are changed.
but because this is a very minor change to the package,
we don't no need to upgrade the major version.

it is good to keep in mind that trying to avoid breaking changes, but it should not be assumed that no breaking changes could be made.

@calidion commented on GitHub (Apr 18, 2017): consider such a situation : ``` // v1.1.0 function fetch(url, cb) { } // v1.2.0 function fetch(url, options, cb) { } // v1.3.0 function async fetch(url, options) { } ``` the purpose of fetch is not changed, but the paramters are changed. but because this is a very minor change to the package, we don't no need to upgrade the major version. it is good to keep in mind that trying to avoid breaking changes, but it should not be assumed that no breaking changes could be made.

GiteaMirror commented

2026-04-16 10:24:01 -05:00

@vearutop commented on GitHub (Apr 18, 2017):

@calidion
v1.2.0 is an obvious breaking change (unless function uses options as cb if cb is omitted)
v1.3.0 is a breaking change too (unless there is special argument processing in function)

Things like: public function names, classes names, argument order changes usually are bright abd easy markers of breaking changes. And in most cases these things does not bring anything to code except beauty and style (i.e. not really necessary to deliver a feature). That's why it is a good practice to avoid unnecessary naming/order refactorings or at least combine them in one major upgrade.

@vearutop commented on GitHub (Apr 18, 2017): @calidion `v1.2.0` is an obvious breaking change (unless function uses `options` as `cb` if `cb` is omitted) `v1.3.0` is a breaking change too (unless there is special argument processing in function) Things like: public function names, classes names, argument order changes usually are bright abd easy markers of breaking changes. And in most cases these things does not bring anything to code except beauty and style (i.e. not really necessary to deliver a feature). That's why it is a good practice to avoid unnecessary naming/order refactorings or at least combine them in one major upgrade.

GiteaMirror commented

2026-04-16 10:24:01 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@vearutop
yes. they are.
But should I upgrade packages just because of such small changes?
I don't think so.
normally big changes are accumulated by small changes over time, not by design.
we are not gods to be able to predict everything that is not happening.

@calidion commented on GitHub (Apr 18, 2017): @vearutop yes. they are. But should I upgrade packages just because of such small changes? I don't think so. normally big changes are accumulated by small changes over time, not by design. we are not gods to be able to predict everything that is not happening.

GiteaMirror commented

2026-04-16 10:24:02 -05:00

@vearutop commented on GitHub (Apr 18, 2017):

To me these changes are big and require a strong justification to exist.
The scale of change can be measured by its impact on dependent users. For the example you provided most of users will HAVE to find all affected usages and change arguments order (twice), if you have a popular lib most likely this versioning policy will drastically reduce the popularity. Nobody wants to waste time for nothing.

Avoiding avoidable breaking changes is a sign of respect to your users.

@vearutop commented on GitHub (Apr 18, 2017): To me these changes are big and require a strong justification to exist. The scale of change can be measured by its impact on dependent users. For the example you provided most of users will HAVE to find all affected usages and change arguments order (twice), if you have a popular lib most likely this versioning policy will drastically reduce the popularity. Nobody wants to waste time for nothing. Avoiding avoidable breaking changes is a sign of respect to your users.

GiteaMirror commented

2026-04-16 10:24:02 -05:00

@calidion commented on GitHub (Apr 18, 2017):

My example is a very simple one, but changes from real projects are much more complicated than this one.

I am not saying we should encourage making breaking changes, but that breaking changes should be considered and allowed.

@calidion commented on GitHub (Apr 18, 2017): My example is a very simple one, but changes from real projects are much more complicated than this one. I am not saying we should encourage making breaking changes, but that breaking changes should be considered and allowed.

GiteaMirror commented

2026-04-16 10:24:03 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@vearutop

breaking changes are always causing problems or uncomfortableness, regardless of major or minor versions.
as a pacakge maintainer, your duty is to produce a well tested, well coded and stable packages and let old user unaware of changes when the client users' pakcages are tested and passed with your certain version.
Upgrade or not is not a concern of the maintainer but the client programmer, the client programmer choose to upgrade or not when he sees these changes.
obviously npm(semver based package management system) is bad at giving this right to its users.
npm assumes that all packages should be upgradable within minor version changes.
and its users are suffering from such assumption which makes the whole system very unstable.

it is good to have such rule in mind that minor changes should be compatible.
but it is not in accordance with the fact that we make mistakes and breaking changes can never be get rid of.

so the basic assumption for semver is not true.
and it leads that npm is constantly causing problems due to the false assumption.

@calidion commented on GitHub (Apr 18, 2017): @vearutop breaking changes are always causing problems or uncomfortableness, regardless of major or minor versions. as a pacakge maintainer, your duty is to produce a well tested, well coded and stable packages and let old user unaware of changes when the client users' pakcages are tested and passed with your certain version. Upgrade or not is not a concern of the maintainer but the client programmer, the client programmer choose to upgrade or not when he sees these changes. obviously npm(semver based package management system) is bad at giving this right to its users. npm assumes that all packages should be upgradable within minor version changes. and its users are suffering from such assumption which makes the whole system very unstable. it is good to have such rule in mind that minor changes should be compatible. but it is not in accordance with the fact that we make mistakes and breaking changes can never be get rid of. so the basic assumption for semver is not true. and it leads that npm is constantly causing problems due to the false assumption.

GiteaMirror commented

2026-04-16 10:24:04 -05:00

@klehelley commented on GitHub (Apr 18, 2017):

I feel like, in the current discussion, the intent of SemVer is not sufficiently taken into account.

Say I am a user of an API that follows SemVer. This is my workflow :

I see a new PATCH version is available. Coming from the previous version, I expect to be able to just bump the dependency and my code still compiles, all my tests are green, and I may have performance improvement or bugs that I did not know affected my code fixed as a bonus. Effort : negligible.
I see a new MINOR version is available. Coming from the previous version, I expect to be able to just bump the dependency and my code still compiles, all my tests are green, and I may have performance improvement or bugs that I did not know affected my code fixed as a bonus. I may have warnings if parts of the API have been deprecated, and I may be offered additional tools by the API that may be worth using. I may plan some changes following that. Effort : minimal.
I see a new MAJOR version is available. Coming from the previous version, by bumping the dependency I may be lucky and have everything working at once, say because I used a subset of the API that did not change. But I may also have code that does not compile anymore, or a lot of red tests. One thing is for sure : the likelihood of my code having to change to accommodate the new version of the API is high. Effort : notable.

This, in a nutshell, is what SemVer brings to me as a user of an API.

If breaking changes are allowed for new MINOR versions, then what is the difference between MAJOR and MINOR? Maybe there is one, but that rationale is out of the SemVer specs, and thus one cannot pretend to just use SemVer while managing their version numbers this way.

In the current discussion, I fail to see a compelling argument in favour of allowing breaking changes with MINOR versions. Doing so would make version numbers less useful than SemVer allows them to be IMO.

@klehelley commented on GitHub (Apr 18, 2017): I feel like, in the current discussion, the intent of SemVer is not sufficiently taken into account. Say I am a user of an API that follows SemVer. This is my workflow : - I see a new PATCH version is available. Coming from the previous version, I expect to be able to just bump the dependency and my code still compiles, all my tests are green, and I may have performance improvement or bugs that I did not know affected my code fixed as a bonus. Effort : negligible. - I see a new MINOR version is available. Coming from the previous version, I expect to be able to just bump the dependency and my code still compiles, all my tests are green, and I may have performance improvement or bugs that I did not know affected my code fixed as a bonus. I may have warnings if parts of the API have been deprecated, and I may be offered additional tools by the API that may be worth using. I may plan some changes following that. Effort : minimal. - I see a new MAJOR version is available. Coming from the previous version, by bumping the dependency I may be lucky and have everything working at once, say because I used a subset of the API that did not change. But I may also have code that does not compile anymore, or a lot of red tests. One thing is for sure : the likelihood of my code having to change to accommodate the new version of the API is high. Effort : notable. This, in a nutshell, is what SemVer brings to me as a user of an API. If breaking changes are allowed for new MINOR versions, then what is the difference between MAJOR and MINOR? Maybe there is one, but that rationale is out of the SemVer specs, and thus one cannot pretend to just use SemVer while managing their version numbers this way. In the current discussion, I fail to see a compelling argument in favour of allowing breaking changes with MINOR versions. Doing so would make version numbers less useful than SemVer allows them to be IMO.

GiteaMirror commented

2026-04-16 10:24:04 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@klehelley

so how do u explain why currently npm packages keep breaks?

your idea of keep your testing green is good, but it still breaks very often.
not the package maintianer is unaware of the goodness of semver, but versions are always breaking just like testing failures.

semver and npm version management doesn't promise the stability of a package. so even the restricted rules exists, you should be wise enough to keep in mind that human beings tend to make mistakes.

these rules are good wills no realities, that is why I would like to point out.

even the PATCH cloud be broken.

the only thing that causes problems is auto upgrade.

you needs no upgrades when you packages are working.

if there is no auto upgrades, packages will never get wrong dependent packages.

so the wrong assumption caused the wrong rules, then caused the wrong version system, then caused the package breaks.

it is nothing to do with the compatibility of patch, minor or major versions.

it is no need to discuss what the semver is and what it should be expected.
because the reality has been neglected at the first place.

the assumption that people don't make mistakes is not true.

it is right we hope most packages are stable at most time, but there are occasions they are not. and these occasions causes breaks too, regardless of major, minor or patch version changes.

so how can anyone keep rules surely be broken someday, sometimes?

@calidion commented on GitHub (Apr 18, 2017): @klehelley so how do u explain why currently npm packages keep breaks? your idea of keep your testing green is good, but it still breaks very often. not the package maintianer is unaware of the goodness of semver, but versions are always breaking just like testing failures. semver and npm version management doesn't promise the stability of a package. so even the restricted rules exists, you should be wise enough to keep in mind that human beings tend to make mistakes. these rules are good wills no realities, that is why I would like to point out. even the PATCH cloud be broken. the only thing that causes problems is auto upgrade. you needs no upgrades when you packages are working. if there is no auto upgrades, packages will never get wrong dependent packages. so the wrong assumption caused the wrong rules, then caused the wrong version system, then caused the package breaks. it is nothing to do with the compatibility of patch, minor or major versions. it is no need to discuss what the semver is and what it should be expected. because the reality has been neglected at the first place. the assumption that people don't make mistakes is not true. it is right we hope most packages are stable at most time, but there are occasions they are not. and these occasions causes breaks too, regardless of major, minor or patch version changes. so how can anyone keep rules surely be broken someday, sometimes?

GiteaMirror commented

2026-04-16 10:24:05 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@jeme

there is no auto fixing.
it your packages are wrong on something that the client programmer needed.

your packages are rejected at the first place.

as a client programmer, the thing i needed is never bother me again when my programs are tested and working, keep all things intact and same.

every wrong assumption on compatibility leads to a risk that i would spend more time to look into new problems which means money and time.

@calidion commented on GitHub (Apr 18, 2017): @jeme there is no auto fixing. it your packages are wrong on something that the client programmer needed. your packages are rejected at the first place. as a client programmer, the thing i needed is never bother me again when my programs are tested and working, keep all things intact and same. every wrong assumption on compatibility leads to a risk that i would spend more time to look into new problems which means money and time.

GiteaMirror commented

2026-04-16 10:24:06 -05:00

@klehelley commented on GitHub (Apr 18, 2017):

@calidion I come from a Java background, using Maven everyday, where auto upgrades is not a thing. I have yet to use NPM, but judging from the previous posts in this thread, while auto upgrades can be a dangerous thing, they can be deactivated if needed. So I cannot say much about NPM. However, if NPM is conceived so that the packages it manages have to follow SemVer, and some developers completely ignore that fact, whose fault is it?

Just to put things back in perspective, what you basically claim at the moment is that, in its current form, SemVer is broken.

Nothing wrong with pointing out that SemVer does not work where it is intended to. Actually, this is encouraged so that the specs can be improved and be useful in all the target cases. Though it has to be made clear why it is SemVer that is broken, in the cases described.

SemVer is but a tool, with rules designed to work in a given context, in order to give useful guarantees. It describes a numbering strategy when releasing APIs, nothing less, nothing more. But as with every tool it can be badly used, be it by applying in the wrong context, or by following only some rules and not others.

A small aside about mistakes: people do mistakes, all the time. Hence the need for a PATCH number, bug trackers, etc. But "some people do not follow SemVer" or "some people follow SemVer, except with some versions from time to time" is not really enough of an argument to say that it is broken. However, if you could demonstrate that people who should be following it do not because of a problem with the specs, now we can talk.

In the present case, it looks like your problem is with NPM and some of the dependencies you are managing with it. Were the people behind NPM right to assume that SemVer would be used most of the time? Maybe, maybe not. The best thing to do is to check whether a justification is given in the NPM documentation, and if not found ask the NPM community.

@klehelley commented on GitHub (Apr 18, 2017): @calidion I come from a Java background, using Maven everyday, where auto upgrades is not a thing. I have yet to use NPM, but judging from the previous posts in this thread, while auto upgrades can be a dangerous thing, they can be deactivated if needed. So I cannot say much about NPM. However, if NPM is conceived so that the packages it manages have to follow SemVer, and some developers completely ignore that fact, whose fault is it? Just to put things back in perspective, what you basically claim at the moment is that, in its current form, SemVer is broken. Nothing wrong with pointing out that SemVer does not work where it is intended to. Actually, this is encouraged so that the specs can be improved and be useful in all the target cases. Though it has to be made clear why it is SemVer that is broken, in the cases described. SemVer is but a tool, with rules designed to work in a given context, in order to give useful guarantees. It describes a numbering strategy when releasing APIs, nothing less, nothing more. But as with every tool it can be badly used, be it by applying in the wrong context, or by following only some rules and not others. A small aside about mistakes: people do mistakes, all the time. Hence the need for a PATCH number, bug trackers, etc. But "some people do not follow SemVer" or "some people follow SemVer, except with some versions from time to time" is not really enough of an argument to say that it is broken. However, if you could demonstrate that people who should be following it do not because of a problem with the specs, now we can talk. In the present case, it looks like your problem is with NPM and some of the dependencies you are managing with it. Were the people behind NPM right to assume that SemVer would be used most of the time? Maybe, maybe not. The best thing to do is to check whether a justification is given in the NPM documentation, and if not found ask the NPM community.

GiteaMirror commented

2026-04-16 10:24:07 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@jeme

auto upgrade is due to the assumption that minor versions should be compatible, semver is the source for that problem.

And it is being conviced that auto upgrade is not right and at lease problem causing. as a sequence the rules from semver is also not correct, and it is good to embrace the practise that the compatibility should be recommended and keep aware of the possible breaks which are inevitable.

@calidion commented on GitHub (Apr 18, 2017): @jeme auto upgrade is due to the assumption that minor versions should be compatible, semver is the source for that problem. And it is being conviced that auto upgrade is not right and at lease problem causing. as a sequence the rules from semver is also not correct, and it is good to embrace the practise that the compatibility should be recommended and keep aware of the possible breaks which are inevitable.

GiteaMirror commented

2026-04-16 10:24:07 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@klehelley

yes. that is why maven is better in keeping package stability than npm due to no auto upgrade and the semver idea.

semver is a tool and a good try on version management and semver draws a very good vision on how version updates should be.

but it is not realistic and applicable.

even if you keep compatiblity in mind, you can not say that your will not making breaking changes, not just apis paramters, but aslo the logics inside.

it is not that everyone likes to break rules, it is that breaks just happen.

I am not saying that we should not keep apis stable, what am saying is that it is not possible to keep such stability all the times. if you take that assumption, you are pushing your self into that risk of package unstability.

so the assumption is not true.

if the basic assumption is not true then all the subsequential rules cannot be true.

that is why node projects brokes constantly when you make a new npm install .

it is not a problem of the package creators/maintainers, it is the problem that npm based on a wrong assumption.

so the semver is somewhat misleading.

and npm is a perfect example for such misleading.

the solution for that npm problem is very simple:

assume no compatiblity on version changes.
stop using version range and auto upgrade.
stop pushing package users to upgrade.

the idea of upgrading or auto upgrading is not good, which may make versioning somewhat meaningless.

versions are releases you can fallback for when mistakes are made.
who dare say his next version is always better than his previous version?
if not, why should you always auto upgrade to a new version?

@calidion commented on GitHub (Apr 18, 2017): @klehelley yes. that is why maven is better in keeping package stability than npm due to no auto upgrade and the semver idea. semver is a tool and a good try on version management and semver draws a very good vision on how version updates should be. but it is not realistic and applicable. even if you keep compatiblity in mind, you can not say that your will not making breaking changes, not just apis paramters, but aslo the logics inside. it is not that everyone likes to break rules, it is that breaks just happen. I am not saying that we should not keep apis stable, what am saying is that it is not possible to keep such stability all the times. if you take that assumption, you are pushing your self into that risk of package unstability. so the assumption is not true. if the basic assumption is not true then all the subsequential rules cannot be true. that is why node projects brokes constantly when you make a new `npm install` . it is not a problem of the package creators/maintainers, it is the problem that npm based on a wrong assumption. so the semver is somewhat misleading. and npm is a perfect example for such misleading. the solution for that npm problem is very simple: 1. assume no compatiblity on version changes. 2. stop using version range and auto upgrade. 3. stop pushing package users to upgrade. the idea of upgrading or auto upgrading is not good, which may make versioning somewhat meaningless. versions are releases you can fallback for when mistakes are made. who dare say his next version is always better than his previous version? if not, why should you always auto upgrade to a new version?

GiteaMirror commented

2026-04-16 10:24:08 -05:00

@klehelley commented on GitHub (Apr 18, 2017):

Your last post has achieved to convince me: you have gripes with NPM and the fact its assumptions are not widely shared amongst the Node community.

Nothing here to do with SemVer.

even if you keep compatiblity in mind, you can not say that your will not making breaking changes, not just apis paramters, but aslo the logics inside.

The logic behind the API should follow the rules laid out by the API. Thus, unless there is a bug somewhere, or the rules the API plays by are too loosely constrained, two different versions of a library implementing a given API, in a similar context and given the same arguments should provide the same results. There may be a whole system with lots of moving parts behind the API, and a lot of things could change in-between two versions. But as long as these two versions implement the same version of the same API, you should be able to use one or the other without having to change your code.

I am not saying that we should not keep apis stable, what am saying is that it is not possible to keep such stability all the times. if you take that assumption, you are pushing your self into that risk of package unstability.

Do note that SemVer does not say anything about the frequency of MAJOR releases. If for a given project someone feels like making breaking changes to their API and releasing them several times a week, SemVer is fine with it as long as for each of these versions the MAJOR number is increased. Of course, this is unrealistic since, with such a frequency of change, who would want to use that API? But then, that is a problem with the API designer, not with SemVer.

it is not a problem of the package creators/maintainers, it is the problem that npm based on a wrong assumption.

so the semver is somewhat misleading.

Huh? I fail to see any link between these two statements. "There is a problem with NPM, let's conclude that SemVer is broken." How is that logic?

@klehelley commented on GitHub (Apr 18, 2017): Your last post has achieved to convince me: you have gripes with NPM and the fact its assumptions are not widely shared amongst the Node community. Nothing here to do with SemVer. > even if you keep compatiblity in mind, you can not say that your will not making breaking changes, not just apis paramters, but aslo the logics inside. The logic behind the API should follow the rules laid out by the API. Thus, unless there is a bug somewhere, or the rules the API plays by are too loosely constrained, two different versions of a library implementing a given API, in a similar context and given the same arguments should provide the same results. There may be a whole system with lots of moving parts behind the API, and a lot of things could change in-between two versions. But as long as these two versions implement the same version of the same API, you should be able to use one or the other without having to change your code. > I am not saying that we should not keep apis stable, what am saying is that it is not possible to keep such stability all the times. if you take that assumption, you are pushing your self into that risk of package unstability. Do note that SemVer does not say anything about the frequency of MAJOR releases. If for a given project someone feels like making breaking changes to their API and releasing them several times a week, SemVer is fine with it as long as for each of these versions the MAJOR number is increased. Of course, this is unrealistic since, with such a frequency of change, who would want to use that API? But then, that is a problem with the API designer, not with SemVer. > it is not a problem of the package creators/maintainers, it is the problem that npm based on a wrong assumption. > > so the semver is somewhat misleading. Huh? I fail to see any link between these two statements. "There is a problem with NPM, let's conclude that SemVer is broken." How is that logic?

GiteaMirror commented

2026-04-16 10:24:08 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@klehelley

if changes to affects nothing, why should these changes be made and released?

@jeme

I have searched npmjs.com

https://www.npmjs.com/search?q=maintainer:jeme&page=1&ranking=optimal

with no package.

I don't know why you are so sure about your idea?

I am wondering if you ever released a package.

@calidion commented on GitHub (Apr 18, 2017): @klehelley if changes to affects nothing, why should these changes be made and released? @jeme I have searched npmjs.com https://www.npmjs.com/search?q=maintainer:jeme&page=1&ranking=optimal with no package. I don't know why you are so sure about your idea? I am wondering if you ever released a package.

GiteaMirror commented

2026-04-16 10:24:09 -05:00

@klehelley commented on GitHub (Apr 18, 2017):

@calidion

I never said nothing had to change. Behind a single version of an API, a lot of things can change: bugs can be fixed, architecture can be improved (for example to improve performance), back-end technologies can be replaced. Even the language used can change!

But of course, it can only go so far. At some point one will want to add functionalities, resulting in an evolution of the API, and this a change in version number. The importance of the change and its consequence in the version number, if SemVer is used, is the responsibility of the code maintainer.

@klehelley commented on GitHub (Apr 18, 2017): @calidion I never said nothing had to change. Behind a single version of an API, a lot of things can change: bugs can be fixed, architecture can be improved (for example to improve performance), back-end technologies can be replaced. Even the language used can change! But of course, it can only go so far. At some point one will want to add functionalities, resulting in an evolution of the API, and this a change in version number. The importance of the change and its consequence in the version number, if SemVer is used, is the responsibility of the code maintainer.

GiteaMirror commented

2026-04-16 10:24:09 -05:00

@calidion commented on GitHub (Apr 18, 2017):

@klehelley

an good example is angular 1 that made some breaking changes.
but it did not upgrade to angular 2 or above.
the idea of not making breaking changes to minor version are not realistic and misleading.

react is the joker who makes major version meanless and now its version has reached 15 from its former version 0.x.x.

major version changes means you have made significant changes to your products, not some minor breaks.

if major versions are changed due to some minor breaks, then such major versions are meanless.

@calidion commented on GitHub (Apr 18, 2017): @klehelley an good example is angular 1 that made some breaking changes. but it did not upgrade to angular 2 or above. the idea of not making breaking changes to minor version are not realistic and misleading. react is the joker who makes major version meanless and now its version has reached 15 from its former version 0.x.x. major version changes means you have made significant changes to your products, not some minor breaks. if major versions are changed due to some minor breaks, then such major versions are meanless.

GiteaMirror commented

2026-04-16 10:24:10 -05:00

@vearutop commented on GitHub (Apr 19, 2017):

@calidion why do you insist on your totally invalid and irrelevant to sevmer point? Is it a troll?

Semver is not the only versioning model available, making major bump for architecture upgrade is something about marketing, like half-life 1 and half-life 2, it has nothing to do with breaking changes or dev efforts.

Meanwhile semver is all about dev efforts on upgrade.

If angular uses major version to tag new architecture instead of breaking changes, it just means that angular does not follow semver (and you should not expect semver behaviour from it).
Having breaking changes within one major means they failed to design it properly.

There is nothing wrong with react having v15, it is still better than having v2.2 and no idea if it is compatible with v2.1.

If you are concerned with too many major versions, semver has a v0 concept.

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

In the end it is YOU and no one else who should take care of your app, setup dependencies with fixed or range versions, and make sure app is healthy after any deps upgrade.

@vearutop commented on GitHub (Apr 19, 2017): @calidion why do you insist on your totally invalid and irrelevant to sevmer point? Is it a troll? Semver is not the only versioning model available, making major bump for architecture upgrade is something about marketing, like `half-life 1` and `half-life 2`, it has nothing to do with breaking changes or dev efforts. Meanwhile semver is all about dev efforts on upgrade. If angular uses major version to tag new architecture instead of breaking changes, it just means that angular does not follow semver (and you should not expect semver behaviour from it). Having breaking changes within one major means they failed to design it properly. There is nothing wrong with react having `v15`, it is still better than having `v2.2` and no idea if it is compatible with `v2.1`. If you are concerned with too many major versions, semver has a `v0` concept. > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. In the end it is YOU and no one else who should take care of your app, setup dependencies with fixed or range versions, and make sure app is healthy after any deps upgrade.

GiteaMirror commented

2026-04-16 10:24:10 -05:00

@calidion commented on GitHub (Apr 19, 2017):

@vearutop

it is wrong to say that angular fails to design properly.
if angular is wrongly designed, then there is no software ever properly designed.

it is even wrong to say breaking changes should result in a major version.
v0 in semver is also an example of violation from what semver is proposed.

if semver is correct on its prospect, there is no need for v0 because every breaking change should result in major upgrade.

@calidion commented on GitHub (Apr 19, 2017): @vearutop it is wrong to say that angular fails to design properly. if angular is wrongly designed, then there is no software ever properly designed. it is even wrong to say breaking changes should result in a major version. `v0` in semver is also an example of violation from what semver is proposed. if semver is correct on its prospect, there is no need for `v0` because every breaking change should result in major upgrade.

GiteaMirror commented

2026-04-16 10:24:11 -05:00

@calidion commented on GitHub (Apr 19, 2017):

It is lucky that angular 1 is not following semver.
so we can clearly feel the differences between angular2 and angular1.
but angular 4 is a wrong choice because it seems angular 4 is no much difference from angular2.
it introduced confusion to the client users and make major version meanless.

@calidion commented on GitHub (Apr 19, 2017): It is lucky that angular 1 is not following semver. so we can clearly feel the differences between angular2 and angular1. but angular 4 is a wrong choice because it seems angular 4 is no much difference from angular2. it introduced confusion to the client users and make major version meanless.

GiteaMirror commented

2026-04-16 10:24:11 -05:00

@calidion commented on GitHub (Apr 19, 2017):

if angular is to obey semver, then you will find angular 20.x in less than one year or you will not get instant fixing due to version control where some bugs will break.

@calidion commented on GitHub (Apr 19, 2017): if angular is to obey semver, then you will find angular 20.x in less than one year or you will not get instant fixing due to version control where some bugs will break.

GiteaMirror commented

2026-04-16 10:24:12 -05:00

@vearutop commented on GitHub (Apr 19, 2017):

And yes AngularJS is not badly designed (i use it and I have released a number of modules for it)...

It is not about how you feel, it is about facts. If you can not update/improve implementation without breaking contract it means your contract had a design flaw (limiting you in some aspect).

It is like by poorly designed contract you expect person name in ASCII, but later you realize Chinese names existence.

If Angular 1 had a perfect design, we would never see Angular 2. If Angular 2 had a perfect design, we would never see Angular 3, 4.

Of course it is next to impossible to produce a perfect design for a complex thing, that's why we have semver v2 (and v3 on the way). But it does not invalidate the fact that breaking changes usually is a sign of incomplete/poor initial design.

@vearutop commented on GitHub (Apr 19, 2017): > And yes AngularJS is not badly designed (i use it and I have released a number of modules for it)... It is not about how you feel, it is about facts. If you can not update/improve implementation without breaking contract it means your contract had a design flaw (limiting you in some aspect). It is like by poorly designed contract you expect person name in ASCII, but later you realize Chinese names existence. If Angular 1 had a perfect design, we would never see Angular 2. If Angular 2 had a perfect design, we would never see Angular 3, 4. Of course it is next to impossible to produce a perfect design for a complex thing, that's why we have semver v2 (and v3 on the way). But it does not invalidate the fact that breaking changes usually is a sign of incomplete/poor initial design.

GiteaMirror commented

2026-04-16 10:24:12 -05:00

@calidion commented on GitHub (Apr 19, 2017):

it is the client programmers' duty to choose proper versions while all software will inevitably release bad versions even where semver is restrictively executed.
this semver rules are set for gods, not for human beings, it is theoretical not practical.

@vearutop

we should never have perfect design.
perfect means no more developement or envolution, that is not the real world.
In real world, we develope and we correct, some times we destroy.
nothing should be perfect at first, we just develope.
semver is not perfect either.
in effect, you are constantly breaking your logic.
if semver is designed to make a perfect design, it is wrong at the fist place.

but semver do demand perfect.

it assume that fixings and minor changes should never break which is totally a lie.

so semver is harmful to version control when it is adopted by more and more people.

@calidion commented on GitHub (Apr 19, 2017): it is the client programmers' duty to choose proper versions while all software will inevitably release bad versions even where semver is restrictively executed. this semver rules are set for gods, not for human beings, it is theoretical not practical. @vearutop we should never have perfect design. perfect means no more developement or envolution, that is not the real world. In real world, we develope and we correct, some times we destroy. nothing should be perfect at first, we just develope. semver is not perfect either. in effect, you are constantly breaking your logic. if semver is designed to make a perfect design, it is wrong at the fist place. but semver do demand perfect. it assume that fixings and minor changes should never break which is totally a lie. so semver is harmful to version control when it is adopted by more and more people.

GiteaMirror commented

2026-04-16 10:24:13 -05:00

@vearutop commented on GitHub (Apr 19, 2017):

@jeme I've never said any Angular had a "Bad Design", and I have nothing against improving architecture with breaking major versions.

If something has the best design now it does not mean this design will be still good after some time.

But if you need breaking changes within current architecture it means (even if your architecture is piece of art) that you missed something in the design and now you need to break things to make them better. It is ok, even best things sometimes suck.

@vearutop commented on GitHub (Apr 19, 2017): @jeme I've never said any Angular had a "Bad Design", and I have nothing against improving architecture with breaking major versions. If something has the best design now it does not mean this design will be still good after some time. But if you need breaking changes within current architecture it means (even if your architecture is piece of art) that you missed something in the design and now you need to break things to make them better. It is ok, even best things sometimes suck.

GiteaMirror commented

2026-04-16 10:24:13 -05:00

@calidion commented on GitHub (Apr 19, 2017):

I would like to say that breaking changes should be avoided during the process of development, but it cannot be prohibited. That is a more realistic rule.

I would like to come up different effortless advices:

never update your versions until you really need to. (save your time checking updates)
never assume newer versions are better and with no breaks. (save your from upgrading and breaks)
bear api stability in mind and try to avoid api changes as possbile. (keep your package in good state)
major versions mean architecutre changes (make your change more elligible)
minor versions mean feature additions and bug fixings and minor api changes.(make your version evoluable)
there is no need to keep a non breaking major version, it is false, cheating, confusion introductory(as angular4 is almost the same to angular2, which may confused you from why you should upgrade).

the thing that is wrong from the ground is that some one assume packages should always be upgraded automatically and it is the duty of a releaser that keep all client software working due to auto upgrade.

so semver is a result of that lie or false, which will lead to major version booming and prevent features and improves being added as a whole to the software or packages.

@calidion commented on GitHub (Apr 19, 2017): I would like to say that `breaking changes should be avoided during the process of development, but it cannot be prohibited`. That is a more realistic rule. I would like to come up different effortless advices: 1. never update your versions until you really need to. (save your time checking updates) 2. never assume newer versions are better and with no breaks. (save your from upgrading and breaks) 3. bear api stability in mind and try to avoid api changes as possbile. (keep your package in good state) 4. major versions mean architecutre changes (make your change more elligible) 5. minor versions mean feature additions and bug fixings and minor api changes.(make your version evoluable) 6. there is no need to keep a non breaking major version, it is false, cheating, confusion introductory(as angular4 is almost the same to angular2, which may confused you from why you should upgrade). the thing that is wrong from the ground is that some one assume packages should always be upgraded automatically and it is the duty of a releaser that keep all client software working due to auto upgrade. so semver is a result of that lie or false, which will lead to major version booming and prevent features and improves being added as a whole to the software or packages.

GiteaMirror commented

2026-04-16 10:24:14 -05:00

@calidion commented on GitHub (Apr 19, 2017):

@jeme

what if semver is a bad design?
npm follows semver to be the most unstable package management system ever:)

@calidion commented on GitHub (Apr 19, 2017): @jeme what if semver is a bad design? npm follows semver to be the most unstable package management system ever:)

GiteaMirror commented

2026-04-16 10:24:14 -05:00

@CyrilWork commented on GitHub (Apr 19, 2017):

Don't waste your time and energy, this topic has enough information already. Thank you jeme, vearutop for nice explanations.

@CyrilWork commented on GitHub (Apr 19, 2017): Don't waste your time and energy, this topic has enough information already. Thank you jeme, vearutop for nice explanations.

GiteaMirror commented

2026-04-16 10:24:15 -05:00

@jwdonahue commented on GitHub (Nov 28, 2017):

Please close this issue.

@jwdonahue commented on GitHub (Nov 28, 2017): Please close this issue.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1138