Semantic Versioning – Handling Bugfixes and New Features in Same Release

After you release your software, the version number should be incremented immediately.

Why?

Let's assume you're following a scheme like Semantic Versioning, and you have a build number in the version. So you might have [Major].[Minor].[Patch].[Build]. I am going to call the [Major].[Minor].[Patch] part the version.

You will be creating multiple builds during development. Each build is a development snapshot of your next release. It makes sense to use the same version for your development and release builds. The version indicates what release you're working toward.

If you're preparing for release and the software passes all of its tests, you won't want to rebuild and retest the software just because you had to update the version. When you eventually make a release, you are stating that "build 1.1.0.23" shall henceforth be referred to as "version 1.1.0".

The increment-after-release model makes sense for branching too. Suppose you have a mainline development branch, and you create maintenance branches for releases. The moment you create your release branch, your development branch is no longer linked to that release's version number. The development branch contains code that is part of the next release, so the version should reflect that.

Should I release these packages with different version names using Semantic Versioning? In my opinion, yes, but what about the naming of these different versions?

You should not change the version unless your code changes. However, your current approach of appending the library version works fine under the rules of Semantic Versioning, but you have to use a + sign to add the library dependency:

• 1.0.0
• 1.0.0+json-c-0.10

For realeasing, and assuming your package name is purestjson this gives:

• purestjson-1.0.0
• purestjson-1.0.0+json-c-0.10

Rationale: Semantic Versioning states in rule 10:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.