Is it appropriate to convert a project to a different language and keep the same versioning?

Question

Say there's a package, foo. Foo is being developed primarily in Python, up until version 1.13.2. At that point in time, the primary developer decides that Go is much better suited to the task. He creates a new branch and codes up a package in Go that has the same functionality or even some improvements to 1.13.2 of the Python version.

Following semantic versioning, is it appropriate for him to merge this into development, bumping the major version, as 2.0.0?

Answer 1

From 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 make backwards-compatible bug fixes.

• Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

What you're describing is build metadata.

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.

Following MAJOR.MINOR.PATCH-prerelease+BUILDMETADATA and since you didn't mention any prerelease status:

1.13.2+Go

If instead he switched to 2.0.0 I would expect it to be a breaking change that meant I would have to rewrite my stuff to make it work because of incompatible API changes. If that isn't true you're losing customers for no good reason.