Allow 3 or more numbers about semver.org HOT 6 CLOSED

how about thinking out the specification for semantic versioning API. For instance, a file with a series of variables like API_CHANGE, API_EXTENDING, PATCH, BUILD, REVISION and so on. And system of version tags with different purposes: API dependency versioning, marketing versioning and so on.

from semver.org.

SemVer is intended for libraries, not huge conglomerate products without a well-defined public API. Keeping the spec simple is paramount, even if it means not working for a few edges cases or very large systems.

from semver.org.

Agreed, but I think this use case stands on its own:
http://msdn.microsoft.com/en-us/library/51ket42z(v=vs.71).aspx

I know these projects would benefit. :)

https://github.com/languages/C%23
https://github.com/languages/Visual%20Basic

from semver.org.

Perhaps my original wording was unnecessarily broad as well. Rather than N reserved parts, just 1 would cover the .NET use case...

from semver.org.

Last bit of additional info: http://blogs.msdn.com/b/jjameson/archive/2009/04/03/best-practices-for-net-assembly-versioning.aspx

from semver.org.

I don't think build numbers belong in SemVer. It's easy enough to use the revision from version control for this purpose, duplicating it in a version number intended for public consumption feels messy.

from semver.org.