-1

Say you have a package Foo that relies on package Bar.

Initially Foo v1.0.0 relied on Bar v1.0.0.

Bar updated to v2.0.0.

You now update the dependencies of Foo so it now requires Bar v2.0.0.

Since this upgrade of Bar does not break, add, or fix any feature in Foo, which part in the semantic versioning of Foo should you update to reflect this change?

Note: In case you're wondering why do I even have to update Bar to v2.0.0 if it won't change anything in Foo -- if other packages in your app also require Bar but at v2.0.0, it will conflict if Foo only requires Bar at 1.0.0. AFAIK this is the behavior in PHP Composer.

IMB
  • 15,163
  • 19
  • 82
  • 140
  • Why not require `Bar` using `^1.0`? – Nico Haase May 19 '20 at 05:33
  • @NicoHaase Sorry I what I meant was `Bar` requires a breaking change `2.0.0`. Updated the details for clarity. – IMB May 19 '20 at 05:35
  • If `Foo` is able to work with both v1 and v2 of `Bar`, you can depend on both using `^1.0|^2.0` - that's how Symfony structures their requirements – Nico Haase May 19 '20 at 05:37
  • @NicoHaase I didn't know about pipes, will try that. So if I set `Foo` to use `^1.0|^2.0`, same question applies I guess, what will be the semver of `Foo` now? – IMB May 19 '20 at 06:33
  • Does this issue a breaking change for `Foo` or not? If not, there is no need to issue a new major version from my point of view. I don't think there is a globally true answer to that question – Nico Haase May 19 '20 at 06:40
  • @NicoHaase It doesn't change anything but if I don't set a new version, the "updated" package with pipes versioning will never be downloaded via composer right? – IMB May 19 '20 at 06:42
  • Unless any other package **explicitly** requires that new verion of `Bar`, it is not downloaded – Nico Haase May 19 '20 at 06:55
  • This question has been [asked many times](https://stackoverflow.com/search?q=%5Bsemver%5D+transitive+dependency). One of them is probably an effective duplicate... – jwdonahue May 20 '20 at 20:28
  • Does this answer your question? [Should a package major version change mean a sub-package major version change?](https://stackoverflow.com/questions/59247866/should-a-package-major-version-change-mean-a-sub-package-major-version-change) – jwdonahue May 20 '20 at 20:32
  • @yivi nothing, I upvoted your comment in the other answer btw. – IMB May 21 '20 at 14:03
  • Ok I upvoted now. I didn't downvote that previously. – IMB May 21 '20 at 14:49

1 Answers1

0

Unless your package is a meta-package built to provide the package Foo, technically, it wouldn't require a change of version.

If you declare your dependency using version ranges (because from the point of view of your package you can depend on any version irrespectively), so it becomes:

"foo/foo": "^1.0 || ^2.0"

The public API of you package hasn't changed at all. Or at least it shouldn't. The internals of your package are not the business of your package consumers, if you are correctly encapsulating your dependencies.

You are not adding or changing features, you are not breaking backwards compatibility. At most it's a patch to redeclare your dependencies, nothing more.

I'd be fine bumping Foo to 1.0.1, to make the change in dependency declaration explicit, but nothing else. (Also, users of 1.0.0 and users of 1.0.1 would be effectively installing different libraries; so not changing the version number at all would be misleading, IMO; and not changing the version wouldn't allow package consumers to get the version with update Bar, if they needed it).

Still, it's a matter subject to a fair degree of opinion. You may want to read this lengthy discussion, for example.

yivi
  • 42,438
  • 18
  • 116
  • 138
  • Thanx! What if the change happens in **dev** dependencies of `Foo` (e.g., a linter, a formatter, a testing library, ...)? Not sure if bumping `Foo` to `1.0.1` is a good idea in this case. – floatingpurr Jul 21 '22 at 08:05