3

There are a few threads about how to handle the version number with semver upon changes in dependencies (usually resulting in a +1 to the patch number). Mine is probably a corner case: what if you are just updating a development dependency (e.g., a linter, a test library, a formatter...)?

Usually, from the user perspective nothing changes. Sometimes, nothing changes into the business code at all! However, you are formally in front of a potentially different codebase which relies on a different dependency set. Should I bump my library from, say, 1.0.0 to 1.0.1, or should I stick to the current version number?

Example 1 (Python) Bumped black (formatter), pytest (testing library), and mypy (linter). New versions do not change the business code.

Example 2 (Python) Bumped pytest (testing library) and refactored some tests thanx to the new pytest API. Again, no actual changes to the business code.

4
  • Reason for the downvote? Jul 25, 2022 at 14:44
  • 1
    Can you give an example how your "development dependency" maps to the code base? Are they part of some script or makefile which, for example, contains some environment variable settings? Or are they just part of some developer docs?
    – Doc Brown
    Jul 26, 2022 at 7:46
  • 1
    ... and concerning the unexplained downvotes: we have same community members here which regularly confuse the right for applying such downvotes without explanations with "the right thing to do" when they don't like a post. That is their problem, don't take it personal.
    – Doc Brown
    Jul 26, 2022 at 7:51
  • @DocBrown thanx for the clarification. I've just added a couple of examples Jul 26, 2022 at 8:06

3 Answers 3

4

Based on the Semantic Versioning specification, any changes to a versioned package must result in the release of a new version of the package.

If the development dependency is not part of the versioned package, then you don't need to do anything with the version. You could optionally use the build metadata portion to identify the changes to other parts of the versioned package, such as the development dependencies.

However, if the development dependency is part of the versioned package, then you would need to increment the version. The major and minor versions are both defined with changes to the public API. Since a development dependency update, by itself, doesn't change the API, these aren't appropriate. This leaves the patch version.

The patch version is described as incrementing "if only backwards compatible bug fixes are introduced" and a bug fix is defined as "an internal change that fixes incorrect behavior". Although updating a development dependency is not a fix for incorrect behavior, it's the only available option.

It is possible to make an argument that you should be using the build metadata component. However, build metadata does not factor into precedence for versions. That means that if you have a version 1.0.1+25072022 and a 1.0.1+26072022 where 1.0.1+26072022 has updated development dependencies, you cannot assert an ordering of these two builds. You probably want to be able to assert that your latest development tools are the preferred version to use going forward.

Although it's not fully consistent with the Semantic Versioning specification, my recommendation would be to increment the patch version.

1
  • Interesting. Dependencies (and dev dependencies) look like a very corner case. Jul 25, 2022 at 14:52
6

If the change in development dependencies is not part of a larger change in the API or internals, don't even increment the version number. This would be considered "work in progress", not a release. Document this in a commit message and a "ReadMe" file.

Semantic versioning does not cover a use case like this, because there is no change to the API. If this change in development dependencies is tied to other API changes, then increment the version number according to changes from the perspective of the consumers of your API, not the people building the API.

4
  • I see. Just to double check if I got it: you should not increment version not even if you change main dependencies. Right? Jul 25, 2022 at 14:50
  • 2
    As long as the API doesn't change from the perspective of consumers, then don't even change the version number. Semantic versioning is concerned with the consumers of your API, not with the people who develop it. Jul 25, 2022 at 16:33
  • got it. If you do not change the API, you can change the patch version. This is usually done for bug fixes. I was wondering if it can be done for (dev) dependencies too. Jul 25, 2022 at 20:33
  • 2
    You can change the patch version, but you don't need to. The consumers of your API do not use the dev dependencies. If the dependency is truly just used by developers, then you have nothing to release. Just document the change in dependency some place for the developers. Even if you change the patch version, consumers of your API might expect a bug fix. If you fixed nothing, then why should consumers of your API install that version? I would just leave the version number unchanged. Jul 25, 2022 at 22:52
2

Adding to Greg's answer:

If the change in development dependencies does not affect the consumer of your library, then you should not release a new version at all.

Simply make the change on your development branch and include it in the next release that affects the users.

If your goal is to rewrite large parts of the library, you might consider releasing a version anyways to ensure that new bug reports still apply. In that case you can simply increment the patch version.

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.