semver / semver.org Goto Github PK

It should be allowed (but not required) to separate the patchlevel and special version number by using a ~ (tilde), the regex for a valid version number (including tags) would then be:

^v?(?P\d+).(?P\d+).?P\d+)~?(?P[a-z]\w+[\d+])?$

If you use this pattern (in python don't know about compatibility to other regex implementations) you can get a nice dictionairy with the keys set to "major", "minor", "patchlevel", "special". This allows easy comparison and further validation

Overall, I welcome the changes in this commit. When we talked last summer, you mentioned adding - as a separator between the patch version and the pre-release string. I’m glad to see it. I also like how you managed to avoid adding a fourth digit (x.x.x.x) by allowing the pre-release string and the new build string to also be dot-delimited.

However, the new requirement of the - between the patch version and the prerelease string means that valid 1.0.0 semantic versions, such as 1.0.0b3 are no longer valid. Given that I maintain two libraries that validate semantic versions, I would prefer that backwards compatibility be maintained. As such, could the - be optional if there are no dots in the prerelease string? Even if the docs say that it may not be used going forward, I think that existing semvers in the wild should still be valid, even if it's only a footnote that says so.

Thoughts?

Thanks,

David

For many software projects a "patch" is an ad-hoc set of files to quickly fix a specific problem (and has no "version" number, although it may have an unrelated "patch" number)
This is rather different to a "bug-fix release".

I would suggest "maintenance version".

I'm wondering how this system will handle pre-release designations.

In Python + setuptools (a flawed system to be sure) there are a ton of pre-release designations with different weights. pre, rc, beta, b, alpha, a, all of which can also take a version, so the ordering is something like:

1.0
1.0rc2
1.0rc1
1.0b3
1.0a4
1.0alpha2

This is, admittedly, too much, but I do think it's usefull to be able to release a package that is intended to be a pre-release version of a particular semver.

Something like appending pre1, pre2 to the end of a semver would be enough so that leading up to a 1.0 release people could be releasing 1.0pre1 1.0pre2, which is simple enough to parse.

This does complicate some of the ordering and dependency version rules but it's problematic for people who want to release betas to have to either do lots of 0.9.99991 designations.

Have you considered releasing SemVer under a CreativeCommons license (or the like)? I think it would ease spreading the SemVer Specification as well as facilitate creating translated versions thereof.

This may or may not be related to semver, but I figure I'll throw it out there:

It would be great to define a common way to access the current version of the library you are using in a given language. For example, a common pattern in Ruby is:

module MyLib
  module Version
    MAJOR = 1
    MINOR = 5
    TINY = 3
    STRING = [MAJOR,MINOR,TINY].join('.')
  end
end

Unfortunately, not all libraries follow this. I'd like to see a recommended way to specify the current version in a variety of languages.

with the central notion of the "public api" semver effectively limits itself to libs. end user apps, that usually do not need to define a public api, could also benefit from semver. especially packagers, distro maintainers and system administrators could benefit a lot from the semver scheme.

conventionally locate a YAML file the project root named .semver.

this file loads a Mapping with the appropriate values defined for the following keys:

• major
• minor
• patch
• special

i implemented this for ruby at flazz/semver. it is available via gemcutter.

In light of the possibility that the specification may be updated, and that projects may begin referring to it at any time, it seems prudent to apply the specification to itself.

From the website:

If all of this sounds desirable, all you need to do to start using Semantic Versioning is to declare that you are doing so and then follow the rules. Link to this website from your README so others know the rules and can benefit from them.

This is great because it lowers the barrier to entry to almost nothing, but it has a couple of problems.

What if tools (such as packaging systems) want to take advantage of the wonderful metadata that semantic versioning provides? The fact that 3.1.0 and 3.1.1 should be interchangeable (and 3.1.1 is better because it has fixed bugs) would be very nice to know when calculating dependencies.

However, this numbering scheme has been used to mean many different things, so a tool couldn't just assume that projects with vX.Y.Z tags are using the scheme.

Another issue is with projects that currently use vX.Y.Z tags but don't use the same meanings for these tags: how do they start using semantic versioning? If they say "we are using semantic versioning" then assumptions about meanings of version numbers won't hold true for the earlier parts of their history.

There needs to be a way to say "as of version X.Y.Z we are now using semantic versioning". Saying that in the README will work for humans but again fails for programmatic use.

The first solution that comes to my mind is pretty simple. Simply add two requirements to the "what you need to do to start using semantic versioning" section:

1. A project is not considered to be using semantic versioning unless there is at least one tag of the form vX.Y.Z somewhere in its history. This should be pretty obvious.
2. A project is not considered to be using semantic versioning unless there is a semver tag that points at a changeset somewhere in its history, and that changeset must also have a vX.Y.Z tag pointing to it.

This solves the problems I've mentioned:

• A tool can tell if a project is using SV by checking for a semver tag and a vX.Y.Z tag pointing at the same changeset.
• A project can declare themselves to be using SV from version X.Y.Z onward by adding a single tag. Tools can parse this and can know to only apply rules relating to SV to versions later than that.

I don't think this is too much of a barrier to entry. Creating at least one vX.Y.Z tag is already a practical requirement -- the only additional command you'd have to run is hg tag -r vX.Y.Z semver. This seems like a small price to pay to allow programmatic detection of this versioning scheme.

Thoughts?

Rather than limit the version number to 3 (major, minor, patch), consider allowing a scheme where the last 3 parts are used for semver and an initial N parts are reserved for vendor-specific semantics. IIRC, .NET Assemblies use 4 parts (major, minor, build, revision). Also, in many development organizations and for many products bumping a major version number implies more than breaking API compatibility. Like it or not, end users associate features with major version numbers especially for commercial, paid software. Nor does a series of iterative evolutions of an API necessarily denote irresponsible development or lack of foresight. It's equally possible to evolve and improve an API over a series of well planned releases containing few, if any new features.

In any case, for projects that want to use 3 parts, great no change to the spec, but allowing projects that want to retain semantic control over major version numbers the option to do so while simultaneously embracing semver and living up to its promises seems like an easy win.

It looks like some doubts are stil existing relating to lexicographic ordering and sorting of the special part (eg. issue #39).
I'd like to propose some enhancements which are already widely in use elsewhere, namely coming from the debian packages versioning scheme, as documented in http://www.unix.com/man-page/all/5/deb-version/
In particular, SemVer may benefit from defining:

• simple explicit ordering instead of pure lexicographic
• using a special pre-sorting character, in particular to denote the special version substring

Quoting from the above manpage, version sorting for debian packages is currently defined as:
"

   First  the initial part of each string consisting entirely of non-digit
   characters is determined.  These two parts (one of which may be  empty)
   are  compared lexically.  If a difference is found it is returned.  The
   lexical comparison is a comparison of ASCII values modified so that all
   the  letters  sort earlier than all the non-letters and so that a tilde
   sorts before anything, even the  end  of  a  part.   For  example,  the
   following  parts are in sorted order: '~~', '~~a', '~', the empty part,
   'a'.
   Then the initial part of the remainder of each  string  which  consists
   entirely  of  digit  characters is determined.  The numerical values of
   these two parts are compared, and any difference found is  returned  as
   the  result  of  the  comparison.   For  these purposes an empty string
   (which can only occur at the end of one or both version  strings  being
   compared) counts as zero.
   These  two  steps (comparing and removing initial non-digit strings and
   initial digit strings) are repeated until a difference is found or both
   strings are exhausted.

"

While this may not be good as-is verbatim, I think SemVer may adopt similar ideas.
This will help SemVer avoiding WTF moment in version comparisons and gaining numbers of already available tools to check version ordering (eg. cmd-line tool, postgres-, perl-, python-, etc- modules).

Given that regex is available in all? languages mentioning the best known dialects and corresponding regular expressions to match would be nice:

Python 2.x:

^v?(?P\d+)\.(?P\d+)\.?P\d+)~?(?P[a-z]\w+[\d+])?$

Is the tagging spec really even necessary? Is that really important to the purpose of semver? I point out that subversion repos often used REL prefixes and not v prefixes.

Personally I stopped using any prefix at all. It makes it very clear what is a release and what is a developers branch, and sorts even better than using v. I discussed this once on a git mailing list and the feedback I received suggested the use of v has arisen simply b/c that is what Linus did on his projects, but there isn't any technical reason that it must be so.

• http://apr.apache.org/versioning.html
• http://www.freebsd.org/doc/en/books/developers-handbook/policies-shlib.html
• http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
• http://home.bolink.org/ebooks/unix3/mac/ch05_04.htm

If you can make it popular in Ruby world you can call it whatever you please :-) You should be able to find 10 (and probably 20) year old rants about how technology X does not do version numbering right, and should use Unix shared library standard.

It's funny, I chatted with Yehuda after his awesome RubyConf 2009 Gems presentation, where he talked about the right way to dependency management, suggesting he add this to the list of best practices that Bundler encourages. He didn't think it would be possible to evangelize this successfully. I'd love to see you prove him wrong.

Tom et al,

If major version 0 is an anything-goes playground, is or should there be any logic applied to minor or patch versions in that context?

If there was some strong opinion on this, it would be great to express it on the site.

I like the work done in the semantic version, it is very much aligned what we're doing in the OSGi, the syntax of the version is almost identical (our qualifier is a fourth field).
However, in OSGi we have the concept of a consumer and provider of an API because we allow different implementations of the same API. For providers of an API we defined the minor as the backward compatibility part and for consumers we defined the major part. Using the mathematical notation we use in OSGi, assuming an API has version 2.3.4.qualifier:

  Provider of an API : [2.3,2.4)
  Consumer of an API : [2.3,3)

I think it would be very valuable if this semantic version paper also explains the difference between consumers and providers of an API. Even better, if we could align somehow.

As stated right now, spec rule number 2 allows for negative integers to be used in version numbers. Is this desirable? If so, it should probably be clarified in the rule - something like the following (emphasis provided for clarity here but should be removed in the final spec):

• A normal version number MUST take the form X.Y.Z where X, Y, and Z are integers. Note that negative integers are allowed. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 < 1.10.0 < 1.11.0.

If not, I suggest revising the rule as follows:

• A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 < 1.10.0 < 1.11.0.

Chris

The following statements are incorrect: "Precedence SHOULD be determined by lexicographic ASCII sort order. For instance: 1.0.0beta1 < 1.0.0beta2 < 1.0.0."

Firstly, the example is wrong. The lexicographic ordering is 1.0.0 < 1.0.0beta1 < 1.0.0beta2, which is clearly not what was intented.

Secondly, lexicographic ordering ignores the numeric nature of the dot components, thus: 1.10.0 < 1.9.0.

An alternative approach would be to specify a canonicalisation of version numbers that ensures the desired ordering. E.g., split the version number into its constituents after appending ~ to an unadorned 3-component version number, as follows:

1.0.0beta1 => [1, 0, 0, "beta", 1]
1.0.0beta2 => [1, 0, 0, "beta", 2]
1.0.0 => [1, 0, 0, "~"]

Part 8 and 9 of the spec should explicitly state that lower-precedence components reset to zero when X or Y is incremented.

What should I do, if I update my own dependencies, while leaving my external API as is - patch or major version update?

When creating a new repo it would be nice to have the option of stating that your library adheres to the principles laid out at semver.org which when selected would display a badge in the #repos div and/or perhaps some sort of boilerplate preface to the readme.

Is this conforming to semver, and if not, what is the reason?

It would be really nice to allow the '.' character as part of the "special version number" so that it could be compatible with with the OSGi semantic versioning definition at http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf.

There are a lot of open-source Java projects that are versioned according to the OSGi semantic versioning definition, e.g.

1.0.0.BUILD

and

1.0.0.RELEASE

Each release should warrant an entry in a changelog. While semver does help communicate the overall magnitude and to a lesser extent, the contents of a change, any project that pushes out a new release really should communicate what those changes are. Bug fixes should be noted, with security issues called out. API changes should be clearly documented. Deprecated methods should indicate replacements. Etc.

tl;dr version:

The SemVer 1.0.0 RTM spec was published twice with changes accidentally. In the first version, the dash was not required for pre-release. In the second version, it was.

The solution we came up with is to call the first version 1.0.0-beta and add a link to that version of the spec with the 1.0.0-beta label (just as we do with the RCs).

That way those that implemented that version of the 1.0.0 spec can point out that they also support this particular revision of SemVer.

For the full discussion, check out semver/semver#49

There is currently no guidance on deprecation in the SemVer spec. Should there be?

If so, I see two paths. Both are consistent with other aspects of SemVer, but one is slightly stricter than the other.

Strict

• When a method is removed, the major version number MUST be incremented, and there MUST be a minor release of the previous major version that includes a deprecation notice.
• When a deprecation warning is added, the minor version number MUST be incremented.

Relaxed

• When a method is removed, the major version number MUST be incremented, and there MUST be a patch or minor release of the previous major version that includes a deprecation warning.

NOTE that the implication here is that deprecation warnings are programmatic, not just in the docs.

Thoughts?

I think the part about bumping the major version if making an incompatible change to the public API should be amended. A public API should never be changed. If you want to do so, you should use a different namespace.

The reason for this is most library management system simply won't let you activate two versions of the same library. So, if awesome-gem 2.0 comes out and it's incompatible with awesome-gem 1.2, it's effectively the same thing as introducing a backwards-incompatible change in the 1.x series. Your entire dependency chain needs to either be on 1.x or 2.0 and that's oftentimes difficult to achieve (patching N libraries is problematic and it only takes one to spoil the party).

However, if awesome-gem 2.0 uses the Awesome2 namespace or whatever, you can basically include both versions of the library in a single artifact. Microsoft does this and it works rather well, if not a bit klunky. The nice part about it is an app declares they adhere to particular interface, not a particular version of the artifact, allowing 2.0 to include 1.2 and letting the dependency chain live coexist happily.

Spec says:

"A special version number MAY be denoted by appending an arbitrary string immediately following the patch version. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-] and MUST begin with an alpha character [A-Za-z]. Special versions satisfy but have a lower precedence than the associated normal version. Precedence SHOULD be determined by lexicographic ASCII sort order. For instance: 1.0.0beta1 < 1.0.0beta2 < 1.0.0"

I think this means that if a customer has locked to, say, ~> 1.2, and you release a 1.3.0alpha1, that would MEET the dependency, right? 1.3.0alpha1 "satisfies but has lower precedence than" (the not yet existing) 1.3.0, which means it meets ~>1.2.

But I don't think this is the intention of 1.3.0alpha. Rather the intention of 1.3.0alpha is to essentially return you to a little breakout psuedo-major-level-0 unstable sequence, sort of. Or I'm not sure about that actually, maybe that's not right. Your thoughts? Is it appropriate that 1.3.0alpha meets ~>1.2? If you release 1.3.0alpha1, is it in fact correct that a dependency manager would auto-update a ~>1.2 project to 1.3.0alpha1? That doesn't seem right.

From the other side, when is it appropriate to tag something with a "special version" subdividing a patch level?

You might be interested to read my article at http://www.1729.com/blog/DisorganizedIncrementalSoftwareDevelopment.html , which I wrote a while ago. It describes a more extreme solution to the problems of versioning and dependency management. Basically you use cryptographic hashes of interfaces and implementations as your version numbers. (A bit like Git does with source code.)

major.minor.patch fails to handle the case where some fuzzily-defined
high-level API intent is nailed down in a later revision in a manner that
could be breaking.

Bumping the major number isn't quite right because to many people
working at a low level, the library/program doesn't even really feel different.
It actually feels like a patch -- and if the marketing department starts
weighing in on things, they'll often force the issue. To them, version
numbers are about intended capabilities not strict backward compatibility.

Proposal: intent.major.minor.patch
Where:

• intent -- The version of a perhaps fuzzily-defined set of capabilities intended & marketed
• major -- The strict backward compatibility version, bumped for even the slightest semantic change/reinterpretation
• minor -- The backward-compatible change version (e.g.: backward-compatible features added)
• patch -- The bug fix version.

Thus:

• 4.0.0.0 is an unreleased version of an absolutely brand-new API intent (4) before any augmentation or QA
• 4.0.0.1 is an unreleased version of API intent 4, with a bugfix that was caught before any API augmentation
• 4.0.1.0 is an unreleased version of API intent 4, with an augmentation but no bugfixes yet.
• 4.1.0.0 is the first released version of API intent 4 (prior to release it was release candidate 4.0.x.y).
• 4.1.0.1 is the first bugfix of the released version 4.1.0.0
• 4.1.1.0 is the first backward compatible change to released version 4.1.0.x
• 4.2.0.0 is the first potentially breaking change to API intent 4 (e.g: the previously published version 4.1.x.y).

Note how separating API intent from strict API compatibility avoids confusion
over bumping the highest version number when only subtle (but potentially
compatibility-breaking) refinements in the interpretation of an API spec have
taken place.

This scheme also helps to prevent a divergence between "engineering" and "marketing" version numbers
(c.f.: JDK 1.6 == Java 6) -- engineers, release management, and product management often see things
quite differently. Keeping all parties well clear of astonishment saves a lot of grief.

Aside: This still plays nicely with #40 (Debian pre-sort characters)

In the FAQ you state that updating a dependency does not affect the public API but I don't think that statement always holds water. I don't have a concrete example but I could imagine a situation where your code relies on a 3rd party library that produces data that is returned by your API.

E.g., lets say you have an application that takes a string as input, performs some type of transformation on the string, and then returns the resulting string. Lets also say this transformation is performed by a 3rd party library called "string-thingy-1.0.0." This means that your API is dependent on the API of 3rd party library. Imagine if the creators of string-thingy release version 2.0.0, which introduces a change in the result of the transformation function you are using. If you upgrade to this new version you have now broken your own API.

If your app/lib relies on only semver projects, then you could probably devise some safe rules about upgrading dependencies. If not, then all bets are off. The library may have broken it's API during a patch level release...the only way to know would be to read the release notes and test.

What do you think?

Given a project where development is ongoing, and releases happen by setting the version in an application description file and tagging that commit...

If you make a subsequent commit to that project before releasing it - what would you recommend the version number of the HEAD revision be?

ie.

rev 1: hack hack hack
rev 2: version = 0.1.0 (tag v0.1.0)
rev 3: hack hack hack

At revision 3, if someone were to checkout/build the head revision, the project would report itself as v0.1.0, but would actually be a newer version.

The spec does not explain why vX.Y.Z is better than X.Y.Z. It seems right but I can't come up with a solid rationale.

Rule #2 says that the version numbers "increase numerically" but this only implies that they increment by 1. Increasing by 3 is still a numerical increase. Even the example uses the less than sign rather than some kind of implication or chaining

If you care about the numbers only incrementing by 1 (which really annoys my friend Lauri when people don't do it) then this should be made explicit.

The Rack developers and I are confused whether it is required to prefix version tags with a v (rack/rack#185).

The first part of SemVerTag uses the RFC SHOULD keyword, implying that SemVerTag is merely a suggested best practice:

This sub-specification SHOULD be used if you use a version control system (Git, Mercurial, SVN, etc) to store your code.

However, the first numbered item in SemVerTag uses the MUST RFC keyword when discussing the v prefix:

When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".

Could you clarify this for us, when following SemVer and using an SCM, is prefixing version tags with a v required or optional?

SemVer specifies 1.2.3beta1 format, while RubyGems uses 1.2.3.beta1. :(

This isn't a complaint - and I don't know what to do about it - but it may be worth thinking about anyway: Not uncommonly, user code relies on "wrong" behavior in the library, and it therefore broken by bug fixes. Either:

• The old version did not match the spec (API), and the new version does, or
• Both versions match the spec, but the new version is somehow better.

In either case, ideal theoretical user code which relied only on the spec wouldn't be broken by the change, but real code might be. This situation probably just comes down to good judgment, but maybe the Semantic Versioning standard can offer some guidance.

Do you intend for your semver spec to define the relationships between the Major/Minor/Patch numbers? At the moment rule #2 implies that the individual components increment independently. For example

1.9.0
1.10.0
2.10.0

With no resetting of the Minor release number. If you care, then maybe there should be a clause that says that the Patch number resets to 0 when the Minor release number increments, and the Minor number and Patch number reset to 0 when the Major number increments.

Currently i am at my own version 2.1.0.116
Now i want to introduce SemVersioning.
Ok, i have to set the Tag: SemVerTag in i.e. SVN.

But which vX.Y.Z MSUT i use?

Is it a good idea to use: v2.2.118 or v2.2.0 ?

Cheers Roland

There is a common problem in naming libraries when the library itself is versioned, but also implements a version of a protocol. For example, python's httplib2 (a rethinking of http 1.x support), and the many imaginings of memcache support.

How about some guidance on this naming problem?

-- ?
So the existing python-oauth2 should be properly named something like:
python-oauth1-simplegeo

v2.0.0-rc.1 removed Tagging Specification (SemVerTag) ?

Which removed:
'When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".'

Any reason?

The addition of the SemVerTag subspec is useful for tools that interact with projects in VCS; however, it doesn't provide for tool chains that work over distributed packages. I'd suggest the addition of another subspec that adds a SEMVER text file to the distributed form of software packages. This file could contain the URL to the version of the semver spec that this version of the package is using. You could extend this further, adding a URL to a webservice for the project which could support some kind of REST API that would allow for querying about updates, bad releases, etc.

Just a little clarity since the discussion has come up in relation to one of my projects.

I would like a clear definition of internal vs external API. Many languages have explicit exports for functions from modules. Those explicit exports are those functions that are designed to be used by other modules. They are the API for that module, and a public API for better or for worse. Now bring in intention, just because those modules export an API does not mean that those modules are intended to be used outside of the library they are a part of. So does a change to the exported API of a module that is not designed to be used outside of the library constitute a change of the Public api and require a minor version change, or is it a patch version change?

The relevant piece of the doc is here ->

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.

Spec states:

This sub-specification SHOULD be used if you use a version control system (Git, Mercurial, SVN, etc) to store your code. Using this system allows automated tools to inspect your package and determine SemVer compliance and released versions.

When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".

Given that multiple software projects may be stored in the same repository, a tag like "v3.1.0" is ambiguous with respect to which software project it applies to. In some VCS this may not be an issue (with SVN you can have a tags directory for each project); for others it will be (tags in git exist in a shared namespace for the whole repo).

One solution would be to permit the name of the project in the tag name, e.g. "foo-3.1.0", "bar-2.3.4".

In looking at SemVer, it seems to only be concerned with how you version public APIs, which is great. But one thing we're struggling with is how to best manage internal-only nightly/continuous builds.

We want to set up an internal package manager server (NuGet) to share libraries with other teams in our org who are not in our source repo. The problem becomes, when we're starting to work on 1.0.1beta, we need a way to version each build of it (multiple builds could happen in a day). We want to reserve 1.0.1beta for the actual public release of that beta.

If you're interested in the full details, I wrote it up in my blog.

One thought we had would be to have an optional extension to SemVer that made use of a fourth version part. This part would represent the build number for the release and is intended only for internal consumption. Sharing among teams. From a public API perspective, the build number should not be relied upon.

Internally, when sharing with other teams, we'll have the benefit of having all of our packages with the same public version, 1.0.1beta, but the build number can be used to determine last known good builds.

The sorting would be something like this (note, I'd probably use a number that represents the date in a real situation rather than 00X):

• 1.0.1alpha
• 1.0.1beta.001
• 1.0.1beta.002
• 1.0.1beta.003
• 1.0.1beta

One reason we like this approach is that the public part of the version never changes for a release from build to build. So all of our tools and other collateral doesn't need to change once we stamp a build as final and simply remove the build number.

Would love to hear any thoughts on this proposal.

When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".

I've always tagged my versions as X.Y.Z, e.g. 3.1.0. I pull that directly out with git describe for my apps to report their own versions.

Is there a reason why you’re including blueprint.css and syntax.css? You’re not using any of these at the moment.
If you do not plan on ever doing so, I would be happy to rewrite the CSS for you in 1 file (instead of 5) containing ± 20 lines (instead of, what, like 1000?). This would greatly reduce HTTP requests and file size, i.e. bandwidth.

Just let me know :)

Cheers

Having HTML anchors on semver.org would make linking to specific parts of the page easier, those should be at least on the titles, having them on individual points would be nice too.

When packaging software in RPM, deb or similar formats, bugs can be introduced in the packaging code which require a new package to be released even when none of the non-packaging code has changed. Therefore, please consider adding an additional packaging-specific version to the semver for projects which maintain their own packaging.

Suggested new rules would be:

• If there is packaging-related source included in the project, include a '-R' suffix to the version where R is an integer and R>0
• R increments whenever a packaging-only change is fixed. Examples of packaging-only changes would be spec file changes for rpm packages or changes under the debian directory for deb packages.
• If the X, Y, or Z values change, R should be reset back to 1.

In RPM packaging, the R value is surfaced as the 'Release' tag. In debian packaging, this would be the debian_revision