2

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?

Improve this question
3
  • 1
    Did the public API change?
    – RubberDuck
    Commented Sep 22, 2016 at 0:03
  • @RubberDuck Probably not. If it's a project end-users will use, then maybe some differences. If not, then it's less likely. It depends on what the project is to be honest. Let's just assume the public API does not change.
    – Awn
    Commented Sep 22, 2016 at 0:07
  • If the public API does not change (i.e. previous consumers can update to the new version without any code breaking), then it should be a minor version. How or with what languages the project is implemented should have no bearing on the semantic versioning. For instance, Python packages are frequently rewritten into C for performance reasons.
    – Fengyang Wang
    Commented Sep 22, 2016 at 2:41

1 Answer 1

Reset to default
2

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.

Improve this answer
1
  • 2
    It's just such a shame you didn't convert sooner. I'd have downloaded 1.2.3+Go. :)
    – candied_orange
    Commented Sep 22, 2016 at 5:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.