71

SemVer concerns versioning releases, not commits. If your version control model happens to require that every commit to master be a release, then yes, every commit will need to be tagged according to the degree of the change. Generally, though, projects develop a mostly stable product on master and tag the releases they deem worthy of support. When they do ...


11

Version numbers are allocated to releases. In general not every commit should be a release. There are several reasons for this. Firstly while you say you "test" every commit there are levels of testing. Running an automated testsuite on one machine is all well and good, but in complex software it probablly wont' catch every issue. Some issues may be ...


10

Semantic versioning doesn't apply exclusively to the build system or API interface. It also applies to what the software does and how it interacts with other things. If you make a change that breaks existing clients, that is very clearly an incompatible API change. It doesn't matter that you haven't changed the names of functions or arguments, or whatever. ...


8

Assuming that your changed function belongs to the public API, it appears that your new API version no longer provides the same result for the same input. This is definitely not backward compatible and hence requires a major change (see point 8 of Semantic Versioning): Major version (...) MUST be incremented if any backwards incompatible changes are ...


6

TL;DR: For a release with new features that don't change behaviour of any existing features, increment the minor (Y in x.Y.z) version by one. For breaking changes (especially where an automated workflow or API consumer would be affected) semantic versioning states you must increment the major (X) version. When you do releases, always increment the version ...


5

It depends on the case, and to some degree on your personal judgement: Adding or changing public API documentation to a package changes the package content, so you have to make a new version - see rule 3 of SemVer spec. Changing only the documentation does not break the API or introduce other breaking changes - so it is clear, MAJOR version number does not ...


5

As soon as I start developing and making changes, those changes will be backwards incompatible, so by following semantic versioning, should I already bump it to 2.0.0? But development is in progress and code is still unstable. You answer your own question here: "development is in progress and code is still unstable", so the code isn't ready for release. ...


4

Almost all changes are, by their very nature, forward incompatible: If I fix a bug and release patch, then downgrading will introduce that bug. If I introduce a new feature, then downgrading will remove that feature and so potentially leave the code in a non-compilable state. If I make a breaking change, then that change will be breaking in either direction,...


3

I suggest conceptually re-interpereting the existing version numbers 1,2,3,...,134,135 as semver versions 1.0.0, 2.0.0, 3.0.0... 134.0.0, 135.0.0 Then just follow the rules of semver to decide how to number the next release - 136.0.0 if it may have a breaking change, 135.1.0 if it may contain new functionality, or 135.0.1 if it has no changes other than ...


3

Version numbers should identify a package (executable, library,...) that a user could have access to. Any version numbering you share with your community is telling a user what versions exist. Creating the intermediate version numbers in your example is misleading because there isn't actually a version 2.3.3 that a user could download and run to get that ...


3

What you're describing is referred to as a "servicing release" in this blog post, "Docker Tagging: Best practices for tagging and versioning docker images" by Steve Lasker. As it sounds like you're using a stable tagging approach, changes to the image containing the same version of the software should use the same tag, as illustrated in the same post: In ...


3

I think the key insight here is that whether or not a change is "breaking" has nothing to do with whether or not the change seems, to you, to be a minor or major change, and has nothing to do with how broad the scope or complexity of change is. Instead, the only thing that determines if a change is breaking is: does code that use to work before the change ...


2

SemVer is defined for public APIs only. If your development does not define such an API, you'll first have to interpret SemVer to clarify its use for software without public API or other forms of content. You should not restart your versioning from 1.0.0: for practical reasons, in order to avoid the risk of any confusion with version 1, 10 and 100. ...


2

Choosing which number to start is the easiest part of switching to semantic versioning. Maintaining a semantic version number is a significant investment. Simple versioning makes no promises that any upgrade won't introduce breaking changes, semantic versioning does imply that minor version can be upgraded without breaking changes. This means you must spend ...


2

Seems to obvious to say, but: a version numbers purpose is to let you easily determine what version of the software anyone is running. If there is any chance of anyone having access to a particular iteration of the code, and not otherwise easily be able to determine a unique identifier, then that iteration should have a unique version number. I see this as ...


2

The semantic versioning is meant to manage the dependencies between components, based on their public API: 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. The whole versioning logic is ...


2

will be backward compatible, though as with all major updates, there will be a few small breaking changes The statement is taken out of context and I guess you misunderstand it. Originally there is: Alpert stressed that React Fiber will be backward compatible, though as with all major React updates, there will be a few small breaking changes. ...


1

Will dependents who are building at lower node engine versions have any problems after my update? That depends on how you are using that dependency that caused the update. If that dependency is only used in the testing of your package, but your package itself doesn't use it, then the users of your package will not be affected (at least not immediately). If ...


1

SemVer doesn't really say anything about how you should structure your repository and your workflow around it in order to achieve it. Because it is really just is a standard for naming versions of software. So there really isn't a right or a wrong way to generate those versions. To add two more approaches to what @Gladen has mentioned. One approach I've ...


1

Perhaps a more manageable solution is a Changelog. If your publishing components anyway, there should be a changelog. I'm not talking about checkin comments. I'm talking about a version controlled file describing important changes in the software. Have the file as prepend only. Add major changes with some symbol say asterisk, and minor changes with say a ...


1

Semantic versioning isn't applicable. A website is generally only available in one version at a time, and if readers need to refer to an old version they will do it by date, e.g. "softwareengineering.stackexchange.com as it appeared on 18 September 2019", so the audience of a website generally has no reason to be interested in a version number. The OP didn'...


Only top voted, non community-wiki answers of a minimum length are eligible