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


46

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


44

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


21

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


21

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


20

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


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.


13

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


12

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


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


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


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

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

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


7

I would consider any change that forces a user to modify their code/configuration as a result to be a breaking change. So, in this particular case, I would wait till v2 to introduce the default of enabled=false and would instead add a note in the next minor release that explains this known scenario, that you should explicitly set enabled=false to avoid it ...


7

There are two cases: If you are sure that you will never release a backwards-incompatible version of the older dependency library, and if the implied reduced visibility of the older dependency version does not bother you => use 1.x for the older, 2.x for the newer; All other cases: use a different package name, do not disambiguate by version; However, if I ...


7

Stick with Tom's guide to semantic versioning. Any significant change to a public API must be done at either of the two points: Never At a major release update My vote, by the way, is for the first. But I acknowledge it's only appropriate for trifling things. The problem is maintaining backwards compatibility and making sure you don't break things for ...


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