Question

Lets say I have a function that can be called via an API like $MyFunction and for brevity $MyFunction returns 12. Now lets say I rename $MyFunction to $The12Function but it still returns the same result (in this example the integer 12). Does this warrant a bump to the major or minor SemVer version number?

One could argue that I am not allowing for backwards compatibility because $MyFunction no longer works. However, one could also argue that there is backwards compatibility because you can still return the same result via $The12Function.

Was it helpful?

Solution

From http://semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner, and

PATCH version when you make backwards-compatible bug fixes.

So, in your case, if you don't also maintain the old function name, in order to retain compatibility with older versions of the API you should increment the major version number.

One way to look at it, in order to know if compatibility is broken, would be to imagine that your API and functionality is encapsulated in a library which offers this functionality to other programs. You now make changes to that API. If the programs which linked to the old version of your API need to be changed in order to use the new version of your library, you have broken compatibility and the major version should be changed. You may solve this problem by overriding and maintaining the deprecated old function calls, but it would increase the complexity of the API.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top