What should I do if I update my own dependencies without changing the public API?

[...] Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.

If you'd expect additional code for the latter (new functionality), isn't the former bug fix option a patch level, not a minor level, increment?

Is there/should there be a standard for the alpha segments?

For instance I've seen

Preview: pre, pr, p, preview and preview release
Alpha: alpha, a
Beta: beta, b
Development: dev, d
Release Candidate: rc, r, release, rcandidate
Final Release: f, final, final_release
Milestone: ms, milestone

Is it within the scope of semver to specify a recommended use/abbreviation?

While implementing the Semantic Versioning rules as a class and an assembly attribute in .Net, I noticed that there is no explicit rule when comparing pre-release or build elements of two version strings that have a different number of dot separated identifiers.

An example:
v1 = 1.0.0-rc.1
v2 = 1.0.0-rc.1.20120810

Lexicographic order would suggest that v1 has precedence over v2 as it is shorter. Personally, I would recommend that v2 has precedence as it contains more information, and that's the way I implemented it in my project.

Any thoughts and comments are appreciated!

If I fork a package and make my own changes to it, I don't want to mess with the version number of the original package, but I should still somehow indicate that this is different.

As an example, let's say a package is at 0.2.0. I fork the package and make a minor change (something that would normally result in the version number changing to 0.2.1). Would it be appropriate to make my version number something like, 0.2.0-0.0.1, or is there a better approach?

http://semver.org/ responds with:

There isn't a GitHub Page hosted here, sorry.

Are you trying to publish one?

We'll send you an email when your page has been built. It may take up to ten minutes until your page is available.

Read the Full Documentation to learn how to set up username.github.com

Hi.

I appreciate your efforts on giving developers a common tool for articulating code changes via version numbers. In that difficult area in the coding field fixed semantics are of real value.

Reading 1.0.0-rc.1 of your Semantic Versioning Specification I wondered, what the purpose of rule 3 is. With the exception of the given examples all specified behavior is repeated in the end of rules 8 and 9.

Could this not be condensed in any way?

Best Regards

Thomas

... the minor version and patch version MUST be reset to zero.

What will break if the minor version is not reset to zero while incrementing the major version number? Not resetting it will allow to preserve more or less linear flow of versions on minor (but API breaking) change.

For example, in 1.5 -> 1.6 -> 1.7 -> 2.8 -> 2.9 we can talk about short "version 6" or "version 9" instead of saying the two numbers every time and psychologically rebasing the development to the beginning of major cycle ("2.0" it will seem like "completely new version with new API" rather than "next version + some API change").

May be better be SHOULD be reset to zero or MUST be reset to zero or incremented by one?

A practical case I ran into is using semver with existing packages. When parsing existing lists, it is unclear which packages use semver and which don't.

Would it be possible to add an identifier to simply tell the world the number is using semver and can be parsed as such?

Common practive is using a 'v' to indicate a version number, eg. MyApplication v3.2.1, if the spec could be updated that a semver compliant version number always starts with 'sv' for example (eg. MyApplication sv3.2.1), then it would immediately be clear that the number is parsable using semver and no conclusions can be drawn from any number that doesn't start with 'sv'.

please comment

Suggesting a clarification that ought to be in the text provided the below is accurate:

From reading the specification, when it comes to build or pre, there is no word on how to compare variable segment numbers.

Specifically, what ought to be the result of 1.0.0+build compared to 1.0.0+build.1 and 1.0.0-pre compared to 1.0.0-pre.beta.

As the specification implies that when build is present it takes precedence over absence of build, and normal takes precendence over pre, I assume the following result:

1.0.0+build.1 < 1.0.0+build
1.0.0-alpha < 1.0.0-alpha.1

The examples however show that 1) is not correct, and should be build < build.1. The text ought to be clarified if that's indeed the desired outcome of builds.

Currently the spec calls out major, minor, and patch as "non-negative integers". However this does not actually provide presentation information. All the examples show these non-negative integers represented in decimal form without leading zeros, but it is unclear if this is required. Are the following legal versions according to the spec?

• 1.03.2
• 0xA.2.1
• 2.010.14
• 5.0xc0.03

The version number is seperated very well but the document lacks in defining the different states within one version. Here is my suggestion:

alpha = in development without caring about (old) unit-tests
beta = in development and the old (unit)tests are valid
rc1 = tests for new features are written and valid
rc2 = additional tests had to be written and those were made valid
rc3 = more additional tests that were made valid
...

I just read through the issues and discussions on CodePlex for NuGet, and it seems like the expectation is that build number precedence would be backwards from how it is defined today, allowing daily builds to march toward a prerelease version.

This discussion has the most activity: http://nuget.codeplex.com/discussions/277189

I really feel like we should reverse the precedence so that build numbers would allow you to work toward a prerelease version. That would simplify the logic to the following:

1. Build numbers march toward a prerelease version
2. Prerelease versions march toward a stable release

Presently, the spec has it defined as:

1. Prerelease versions march toward a stable release.
2. Build numbers allow you to put out newer builds of a stable or prerelease version without changing its version.

I guess I’m just not sure why you’d need to have additional builds after a version. Once a version is released, it’s done; new builds should be a new version. If there was something wrong with the version that was released and you need to put out a new build, then it’s a Patch to the broken version and therefore the patch number should be increased.

And perhaps, we should limit build numbers to prerelease versions, as I haven't yet seen evidence for build numbers to be needed on stable versions. If we allow build numbers on stable versions and a user has said they want to opt into "Prerelease" versions, does that mean they also get build-number versions? If they don't want prerelease versions, do they need to opt in/out of build numbers?

Here are some examples that are called out, and discussion participants unanimously agree that build numbers march toward a prerelease version.

EddieGarmon

1. 1.0.1alpha-0001
2. 1.0.1alpha-0002
3. 1.0.1alpha
4. 1.0.1alpha2
5. 1.0.1beta-0003
6. 1.0.1beta-0004
7. 1.0.1beta
8. 1.0.1

Ferventcoder (+1 from xavierdecoster despite that he had previously laid out the ordering as shown in the spec)

1. 1.0.0-alpha.001
2. 1.0.0-apha
3. 1.0.0-alpha1.001
4. 1.0.0-alpha1.002
5. 1.0.0-apha1
6. 1.0.0-beta
7. 1.0.0-rc
8. 1.0.0

EddieGarmon

1. 1.0.1alpha-ci-20111026-1 <-- CI Build
2. 1.0.1alpha-ci-20111026-2 <-- CI Build
3. 1.0.1alpha-ci-20111026 <-- Nightly
4. 1.0.1alpha-ci-20111027-1 <-- CI Build
5. 1.0.1alpha

Haacked

1. 1.0.1alpha~001
2. 1.0.1alpha~002
3. 1.0.1alpha~003
4. 1.0.1alpha

ferventcoder

1. 1.0.0alpha~001
2. 1.0.0alpha
3. whoops - 1.0.0alpha.1

ferventcoder

1. 1.2.10alpha~001
2. 1.2.10alpha~001.1 (fix of build 001 alpha package, not contents)
3. 1.2.10alpha
4. 1.2.10alpha.1 (fix of alpha package, not contents)
5. 1.2.10
6. 1.2.10.1 (fix of 1.2.10 package, not contents)

EddieGarmon

1. 1.2.10alpha~001
2. 1.2.10alpha~002 (fix of build 001 alpha package metadata, not contents)
3. 1.2.10alpha~003 (same package metadata, new contents)
4. 1.2.10alpha (ideally this is a repackage of alpha~003 with just package metadata edits, same contents)
5. 1.2.10
6. 1.2.10.1 (fix of 1.2.10 package or contents)

EddieGarmon

1. 1.2.10-alpha120111017 (CI Build)
2. 1.2.10-alpha220111017 (CI Build)
3. 1.2.10-alpha~3
4. 1.2.10-alpha420111018 (CI Build)
5. 1.2.10-alpha~5
6. 1.2.10-alpha

For convenience the regular expression that parses a valid semver should be made available on the homepage.

JavaScript:

/^((\d+)\.(\d+)\.(\d+))(?:-([\dA-Za-z\-]+(?:\.[\dA-Za-z\-]+)*))?(?:\+([\dA-Za-z\-]+(?:\.[\dA-Za-z\-]+)*))?$/

UPDATE: I think I've collected all of the comments and edge cases to produce a regex and test cases that are in accordance with the spec.

See test cases in JavaScript: https://github.com/coolaj86/semver-utils

semver is defined for public APIs, but is there anything for executable scripts?

I'm sure this would make an interesting question for the FAQ.

Chris

2.0.0-rc.1 states in §10 and §11 that " Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]". This suggests that the pre-release or build part may contain a dash. Since there is no fixed order defined for these parts (apart from precedence calculation in §12), either 0.1.2-alpha-2+b232-3 and 0.1.2+b232-3-alpha-2 would be considered valid, making it impossible to distinguish the version parts.

Usual way to know about semver is read http://en.wikipedia.org/wiki/Versioning#External_links or look at http://stackoverflow.com/search?q=semver

Both of this sources point to http://semver.org/

http://semver.org/ point to https://github.com/mojombo/semver.org/issues

But active commits done under https://github.com/mojombo/semver/issues/new

So backing to subj have http://semver.org/ correct URL to issue report?

What do I do if I accidentally release a backwards incompatible change as a minor version?

As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Remember, it is unacceptable to modify versioned releases, even under this circumstance. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

I suggest that offending version shall be clearly retaged "offending" inner it's version number like this x.y.z-offending

This would allow automated release tools to alert and/or force upgrade to next legit version.
Same benefit for validation team: No need to test/raise issues on offending version.

Offending version can also break dependencies compatibility.

Offending version breacking backwards compatibility shall be realy marked as NASTY without having to search in documentation/release-notes.

The only part of SemVer that evidently clashes with the common "responsible" practice of program versioning is requiring dots between tokens of the pre-release part. I see this has been added between spec version 1.0.0 and 2.0.0-rc.1 -- I claim this is unnecessary and will harm adoption of SemVer.

I am the maintainer of LuaRocks and I have a sorting algorithm implemented for package versions that respects basically the same ordering as that proposed by SemVer, except I don't require the dots. This can be done by considering sequences of numbers [0-9] and alphabetic characters [A-Za-z] as separate tokens, ignoring any further dots and dashes. So, "1.9.3-alpha2-rc3" parses as "1", "9", "3", "alpha", "2", "rc", "3".

An RFC-style document has greater chances of becoming an accepted standard if it closely matches common practice. You see lots and lots of "2.0.0-rc1" out there; there's no technical reason to require that extra dot.

The design for the spec could be enhanced by very few things:

1. In main.css, change the body rule to :
   width: auto;
   margin: 0 10%;
   max-width: 710px;
2. Adding the following meta element to the HEAD section of the html document: <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0"/>
3. Adding the following two rules to the stylesheet:
   @-ms-viewport { width: device-width; }
   html { -webkit-text-size-adjust: 100%; }

And ta-daaaa! The site works with all devices including those narrower than 710px wide. iPhones, Android, everything works, even resizing your browsers.

That said, nice work for the SemVer.

Provide examples of strict (i.e. declared SemVer adoption) and SemVer-like schemes.

Candidates off the top of my head:

• The Kernel as of 3.0.0.
• Qt
• Subversion
• GitHub? (Please say it's so... the irony would just be too much!)
• PostgreSQL

Can we get a changelog file, even if it's just a diff, of the changes between versions of semver?

Ok, the SemVer seems to be related to the tags on the git pattern.

How can I adapt it to the git model and how should I name my branches?

Thanks

Please define whether prerelease version 1.0.0-example and build version 1.0.0+example are mutually exclusive, and if "no," which must be written first.

"Pre-release and build version precedence MUST be determined by comparing each dot separated identifier as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or dashes are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers."

There’s nothing wrong-looking in the Web site examples, but I'm not sure I fully understand this part of the spec. For example, is this true?

1.0.0+1.0.1234.5678 < 1.0.0+build

When you’re comparing apples and oranges like this (e.g. a change of build number strategy), what are the semver rules?

It would be nice, if SemVer was compatible with OSGI -> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

This could be achieved by allowance of additional "qualifier" field from OSGI, before last "+" or "-" character. User may define flags within qualifier for his own purpose. This can be used to denote for example target platform. Some picturesque examples:
1.2.0.win+build.4421, 0.3.1.x86-posix-rc.2.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. For this system to work...

Should be something like:

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules based on pre-existing widespread common practices in use in both closed and open-source software - I am merely formalising them in a rigourous way.

For this system to work...

Reasoning: Make it clear up-front that you didn't "just make this up".

Is 1.5.9 greater or less than 2.0.0-alpha (or -beta, or -rc)?

I'm assuming it is greater.

Currently the spec prescribes how to calculate precedence, but actually mixes this with development order.

The pre-release versions should not be taken into account when determining compatibility, because if you do, it requires updating the major/minor and patch numbers while working on new releases. If the alpha of 3.2.1 has a bug that is fixed in beta of 3.2.1, then it should have been labeled beta for 3.2.2 because of that bugfix.

To fix it; define 2 distinct precedence calculations;

1. Development order: basically the current precedence calculation, including any pre-release tags
2. API compatibility precedence: in this calculation any label that has a pre-release identifier (or a major version 0), should simply be ignored because no compatibility statements can be deduced from the numbers (yet), until it is released (hence the word 'pre-release').

Referring to rule 10:

A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version.

I'd like to point out that you probably mean a hyphen. I know it seems picky, but when making a standard, precision is important.
Dashes are – (&ndash;) and — (&mdash;). Hyphens are -, which is actually on the keyboard.

This change somehow made it into the 1.0.0 spec. That doesn't seem quite right. I should think that this commit would be considered the last in v1.0.0. Am I mistaken? Because otherwise there are three different versions to recognize:

• v1.0.0 which disallows a dash between the patch version and the pre-release version.
• v1.0.0 which requires a dash between the patch version and the pre-release version.
• v2.0.0 which requires the dash and dotted integers.

This makes it difficult to write a parer to properly handle all the cases.

According to the Specification, patch version must be reset to 0 when minor version is incremented and both patch and minor versions must be reset to 0 when major version is incremented. However, it doesn't specify the behavior of pre-release and build versions when the associated normal version is incremented. Supposedly, they shouldn't remain the same, and, if so, it should be explicitly stated in the Specification.

'nuff said

Hi, had some more thoughts on SemVerTag. I posted then at https://github.com/postmodern/sem_ver_tag/issues/3#comment_1323770.
It was recommend to me to post here. So I have reproduced it below:

I believe the requirement of the v on the version tag is limiting for no significant reason. I've explored the issue, and from what I've been able to discern, the only reason the v- prefix has become a common convention in recent years is because Linus uses it. Thus it has become popular with Git users. But there are many more developers in the pond, and many other SCMs. If we look over all of these in general we see a broader pattern.

First off, I do understand what you are saying about these potential tags:

• 1.800.1234567 looks like a Semantic Version number, but is in fact a Telephone Number.
• 4.20.2010 looks like a Semantic Version number, but is in fact a Date.
• 90.7.0FM-KBOO looks like a Semantic Version number, but is in fact the Call Sign for a FM Radio Station.

However, it is very easy to simply not use such tags. And really I doubt many ever would so as to avoid any potential confusion with version tags.

In the larger spectrum of development we can find many conventions.[1] I have seen a number of prefixes used:

• v
• r
• release
• REL
• version
• {package-name}

And of course there is the practice of using no prefix at all --which is quite common. Here is a small list of BIG projects that use no prefix:

• https://github.com/resolve/refinerycms
• https://github.com/jquery/jquery
• https://github.com/visionmedia/express
• https://github.com/documentcloud/backbone
• https://github.com/django/django
• http://drupalcode.org/project/drupal.git
• https://github.com/hibernate/hibernate-core
• https://github.com/cakephp/cakephp
• http://code.google.com/p/google-web-toolkit/
• http://code.google.com/p/mockito/

Looking over the many projects over many source code hosts, the most common choices by far are just three: the use of {package-name}-, the use of the v- prefix and no-prefix at all.[2] By simply opening SemTagVer up to these three possibilities, it would become much more inclusive of many many projects. I really can't think of a good reason to be idealogical about it. And by not doing so, it just opens the door for someone else to create (yet another) standard in competition. Do we really need a "religious war" over these three perfectly viable ways to denote a release tag?

That is the question.

[1] Older Conventions that I came across:

• http://smb.slac.stanford.edu/research/developments/blu-ice/dcsAdmin/node7.html
• http://subversion.apache.org/docs/community-guide/releasing.html
• https://weblion.psu.edu/trac/weblion/wiki/TagArelease
• http://tiki.org/TikiCVSTags

[2] You might wonder why {package-name}- is a common prefix, btw. Turns out some repos hold code for more that one deliverable package. In those cases they have to distinguish them. Hence the package-name prefix.

Hi.

Just looking for some best practice here. Suppose you have an application where you have 2 incompatible "branches": 1.x and 2.x. Now the situation arises that a breaking change needs to be implemented to 1.x. This new change is not compatible with 2.x and should not be included in that branch. In other words, this new breaking change is only for 1.x.

The change does not change the application name or intent. What should the new version be?

Werner

Lets say you update versions of libraries your project depends on and make no other changes. When you re-release your project, which version number should you bump? I think it ought to be the minor number and that it shouldn't depend on whether those libraries broke backwards compatibility. I'm curious what others think.

If there's a consensus, I think it should be covered by the semver document.

It would be nice to have a canonical semver parser with test cases (in lieu of my earlier comment about regexes).

I have a stub here https://gist.github.com/3012865, but it may not be 100% correct yet.

The semver.org spec is excellent, and have specified it for use in software-like artefacts in openEHR.org. The only problem is this part of rule 12:

Pre-release and build version precedence MUST be determined by comparing each dot separated identifier as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or dashes are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.

This is ok for the set of strings 'alpha', 'beta', 'rc-xxx', because they happen to sort in the same order as the lifecycle, but a more general case should be documented in our view, which says that for any given lifecycle consisting of a certain set of states, the order is specified by that lifecycle. So another lifecycle could be made of states like 'pre-draft', 'draft', 'review', 'published', 'obsolete', and the state machine would specify valid transitions.

Given that this part will always be lifecycle specific, I think it would be worth documenting the alpha/beta/rc lifecycle for what it is, and possibly even some other example lifecycles.

Hope this is useful.

• thomas

It is often the case that packages contain breaking changes between, say, a beta 1 and beta 2 build. In the wild, a lot of packages seem to want to achieve their release with a clean "2.0.0" version. As API incompatibilities usually happen between those phases, my understanding of the specification is that the version number should be bumped, which means that you couldn't make breaking changes between beta1 and beta2 without bumping the major version.

So in the wild I've seen people use the pre to version their pre-release, aka 1.0.0-public.beta.1 < 1.0.0-public.beta.2. This introduces issues when releasing packages in-between the two, as there is no version number change the dependency on one version or the other cannot be taken from the package manager.

Another issue is that there may be interemdiary builds between beta 1 and beta 2, and it's unclear how one would go about doing this while preserving the correct order of packages. One could try 1.0.0-ci.25 but that would put any ci build as before any of the beta packages, so it seems to me not bumping the version really causes issues there too.

As far as implementing a package manager that can take dependencies, the specification defines what packages match a dependency (aka 1.0.0+build and 1.0.0-alpha both match a 1.0.0 specification) but does not discuss (allowing or disallowing) how dependency on specific builds or pre versions ought to function, if at all.

In other words, the use of pre tags seems to me to be missing guidance on the following points:

• when should version be bumped between two pre packages
• explicitly state that the order is forward only and it is expected that any future build sharing a version number can only have alpha builds, then beta builds, etc
• discussing how package managers ought to implement dependency declarations (only on version, on version+build, on version-alpha+build?), which i'd suggest should be forbidden on builds and optional on pre (so one could take a dependency on beta.1 instead of just on the version, provided you don't make bumping version numbers mandatory between pre builds)

I see that ~ was removed as a separator, but i think it has its uses. It's actually what Debian uses to mark release candidates as being "lower" than the real release. In fact, it makes the whole thing semantically easier to compare.

Consider: a.b.c > a.b, as a general case. If we say that "dot" can separate "release candidates" strings, then this is not true if c is "rc1", for example (1.0.rc1 < 1.0), breaking the general case (for that matter, 1.0.rc1 > 1.0.0).

So I think that ~ serves a purpose and should be brought back in, which would also mean that this would be compatible with the Debian versionning.

For more information about Debian version numbers and the way they are compared, see: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

in item 7. 8. and 9:

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

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 substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

the conditions x>0 look out of place, shouldn't that be x>=0, y>=0 and z>=0 at their respective descriptors?

Hi. I found the semver doco understandable except I'm confused about the 1.3.7+build.11.e0f985a example. What does that last segment represent? When would I create a version like that?

Thanks in advance,
Jason.

It would make 1.0.0 -> 2.0.0 changes more easy to understand!

semver.es.md

I'm dealing with the flip side of "dependency hell", called "the bleeding edge".

For the past 7 years, I've been balancing R&D with a prototype system used by an international audience. I've created several generations of test encoding forms. There were many disruptive changes along the way and people lost data and had to redo work. I performed several major conversions between 16-bit symbol sets used within similar data structures. I didn't use semantic versioning.

Earlier this year, I accomplished my last design goal. I finally had the data and the time to really tackle the search problem for written sign language, a 2-dimensional script. In October, I successfully determined the final form of the word string and the formal query string. Searching that is fast enough for spell check, auto-suggest, and many other flexible searching.

The answer was regular data with simple regular expressions.

A joke - A programmer had a problem so he decided to use regular expressions. Now he has two problems.

The joke is supposed to be funny because it's hard to write simple, elegant, and fast regular expressions when you are trying to use real world data.

But it's not really a joke if you can evolve with regular expressions. The first problem involves crafting regular data that can be productively searched. The second problem is crafting simple regular expressions that are meaningful and fast.

Each generation pointed the way to the next and require a data conversion and reintegration.

So I realize I've been in an extended gestation period as I've incorporated each new lesson learned. In 2009, I thought I had a somewhat stable standard. At that time, I had a test design mapped out in my head for the search, but I didn't have the data or time to explore it more.

But now that I have achieved all of my design goals, it's time to release a stable, semantically versioned standard. Reading about semver partially shamed me for not following it sooner. The other part was inspired to produce a stable standard now that I was ready.

So I'm writing the Foundation of Modern SignWriting v1 as a 12 part series, using semantic versioning for the specifications. The small reference will be ready 1/12/12. Covered under the Open Font License and Creative Commons by-sa. The large reference will develop in a wiki over time, but always in agreement with the small reference.
http://www.signpuddle.com

Thanks for explaining semantic versioning with such clarity and purpose.

I was using http://apr.apache.org/versioning.html which is pretty much the same as semver, I'm surprised there's not even a mention of it.

You could add some examples insipred by this document to semver.

This article on continuous deployment of gems suggests a mechanism that uses the build number (which is non-decreasing) as the patch. That violates the semver statement (3) that, "When a minor version number is incremented, the patch version MUST be reset to zero." It seems to me that using the build number here both obeys the spirit of semver and the letter of all but this one statement. Most notably, it does not break the meaning of ~> x.y.z.

Hi

Please see this question:

What should I do if the bug that is being fixed returns the code to being compliant with the public API (i.e. the code was incorrectly out of sync with the public API documentation)?

Use your best judgment. If you have a huge audience that will be drastically impacted by changing the behavior back to what the public API intended, then it may be best to perform a major version release, even though the fix could strictly be considered a patch release. Remember, Semantic Versioning is all about conveying meaning by how the version number changes. If these changes are important to your users, use the version number to inform them.

I have difficulty in understanding it. "What should I do if the bug that is being fixed", till here, we talk about the bug, right? "returns the code", what does it mean? Can fixing a bug possibly return "code"? "being compliant with the public API", what's the problem then? I fixed a bug, and now everything is fine, and compliant with the public API. Why should I even up-version? I mean, I understand this as a refactor, more than a change of public signatures of the API.

Thanks.

Hi,
Probably missed something but cannot see any info on the website or in github commit history around what's changed from v1 to v2.

Can you point me in the right direction please

Cheers

It would be nice to provide a standard handling the syntax of version constraints as well, because now this is handled differently in every tool. So it's hard to define the dependencies of your application, when your not familiar with the syntax the used dependency manager supports.

The standard would have to deal with comparison operators, wild-cards and/or stripped versions (support 1.2.* and/or 1.2), multiple constraints (how to list several constraints - just coma separated or support logical operators like AND and OR) and stability (how to include/exclude pre-release or only alpha versions).

Is this the right place for a discussion about this matter?

This FAQ entry:

Doesn't this discourage rapid development and fast iteration?
Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.x.x or on a separate development branch working on the next major version.

Should actually have a "0.y.z" instead of "0.x.x" to fit with how the rest of the document is written.

Thanks!