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 ...


50

Semver is mostly concerned about versioning libraries and packages in a manner that avoids dependency hell, in it's various incarnations. However, the idea behind Semver can be extended to all kinds of programs – any piece of code has some kind of user interface, or it is pretty useless. A programming library or web service has an API. Consumer software ...


47

Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs: Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if ...


29

You hesitate because you don't want to make semantic versioning, you want to make "advertisement supporting versioning". You expect a version number "2.0" to tell the world that you have a bunch of new cool features in your library now, not that you changed the API. That's ok (many software companies and/or developers do that). IMHO you have the following ...


29

Why you SHOULD go for a new major version according to semver? Semver is a recommendation and not a regulation: ultimately, it's up to you to decide, as suggested by Bart. However, if you want to comply with semver, you MUST go to the next major version. First: Once a versioned package has been released, the contents of that version MUST NOT be ...


22

Version numbers are only relevant for releases, since they are a way for external users to identify a specific build of your software. If you're just busy doing development and not releasing each fix individually, then don't worry about incrementing the release number for every fix. It's not relevant to external users and wastes your own time with extra ...


22

It sounds like you are bypassing normal conventions just to avoid process overhead/audits. That... strikes me as concerning. What you are doing is effectively making an extra version number (your minor PCI digit) somewhat intentionally in order to move your feature/minor version numbers back a place, to no longer trigger your internal audit criteria. ...


21

Semantic Versioning seems to be at conflict with most desktop application numbering. We solved this by handing over "product versioning" to the marketing department, and we maintain completely separate (but logical to us) versions for all the components. A specific product version then becomes a defined collection of compatible components. Maintaining ...


16

Usually, for things like semantic versioning, it isn't relevant how you technically achieve something, but rather what the intent is of what you try to achieve. If your intent with the rollback of version 3.0.0 is to offer the features introduced with version 3.0.0 also to users of the 2.x.y versions without forcing a major version update on them, then ...


15

I can tell you how I do it at work. We have a continuous integration server that builds, tests, tags and outputs a versioned package. We only proceed to the next stage if the previous one is %100 successful. Our version looks like this: <Major Version>.<Minor Version>.<Build Number> Every successful build that has no completed bug fix ...


14

I adapted semantic versioning for desktop or web applications, so in our work we are using: X.Y.Z Z is increasing if a release contains just a bug fix, dependencies update or some application internal changes, so no new functionality introduced to user; Y is increasing if a release contains minor changes in UI or just introduces some new feature, or some ...


14

Assuming that the semantic versioning is used properly, does this indicate that the system is poorly designed since it makes major breaking changes almost every four months? Not necessarily. You mentioned in the comments that this is an internal API. Breaking an API is bad, because you break everybody's code. But for an internal API "everybody" is just "...


13

While not being explicit about it, SemVer applies to released packages. Therefore, if you, as release manager, build a package containing all 3 commits then you only have to increment the version once. If you choose to release them in separate packages then you have to increase the version each time you release.


12

First of all, SemVer.org is all about version numbering for libraries and APIs. You can borrow the ideas to use for applications, but note that it's not a perfect fit (for example, SemVer says the MAJOR version number increments when you make a non-backwards compatible API change) You don't work on "FEATURE 2" or "FEATURE 3", you work on "FEATURE {...


11

Assuming that the new features are backward compatible, you should increment the MINOR version number, an reset the PATCH level, . Rationale: semver 2.0.0 makes this crystal clear in clause 7: Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if ...


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 ...


11

Non-contractual behavior is non-contractual. Strictly speaking, it thus isn't something to be concerned about at all, and should only bump the patch-number in SemVer. Unfortunately, some people always think they are clever when they exploit happenstance, instead of coding to the interface, and far more people don't actually know the contract as well as ...


10

I'd recommend making it more stable. Users are the canonical source of what your software does. If they want it, and have come to rely on it, I'd think twice about yanking it. A good example of this is the "Skiing" mechanic in the video game "Tribes". Originally a bug in how the physics engine handled jumping on a hill, it ended up one of the core game ...


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. ...


9

It's my understanding that you have to increment the major version number if your code introduces breaking changes. If Thing is used strictly for input and you're now accepting a couple of new values, then you won't break any existing code. However, if you're returning Thing and I have code like switch (myThing) { case PreExistingValue1: ...


9

There are a couple of things which make backwards compatibility non-trivial. First, one constraint that is often used is that your code will compile without change in a backwards compatible change while in a non-backwards compatible change it may require code changes for your code to compile against the new version. Of course, this constraint isn't useful ...


8

It requires a public API in order to effectively apply it's versioning pattern. For example: Bug fixes not affecting the API increment the patch version Backwards compatible API additions/changes increment the minor version, and... Backwards incompatible API changes increment the major version. What represents your API is subjective, as they ...


8

Since the bug is in a library, here is another approach that you can take: Make a clone of the erroneous library function. In many cases people just append a 2 to the function name in these cases, but, if you have other changes that you would like to apply to the interface of that function, you might also give it a completely different name. Fix the bug in ...


8

In the current version of Semantic Versioning, which is 2.0.0, no. There is a requirement that defines the version as the form X.Y.Z where X, Y, and Z are non-negative integers that do not contain leading 0s: A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major ...


8

why not use simple number based versioning? Android, as most of the software, has also semantic versioning. But, numbers are abstract and hard to sell. However, this does not happen only in the software world. It happens everywhere, the space programs (for example, the space shuttles were not named Space Shuttle 1/2/3.. but rather Columbia, Discovery, ...),...


8

The semantic versioning rules are applied to your software from the perspective of your users. If your API has changed and is not backwards-compatible, you should update your major version number. It sounds like this isn't the case, though. It sounds like your API hasn't changed - clients who were using your previous version can simply drop in the new ...


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 ...


7

You mention that you are looking at using semantic versioning, so lets look at the semantic versioning spec at 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 ...


7

I'm guessing that if a large percentage of users expected it as a feature, it should be left "unfixed" or "fixed" to be more stable? Does the bug add value? If so, it's more of a feature. Sometimes a "bug" can end up as a value-add "feature." It's hard to really answer this conclusively because every single situation will be different. In this specific ...


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