4 ms·

It seems that lockstep versioning makes semantic versioning less meaningful A major version bump for a module could signal a breaking change, or it could just

It seems that lockstep versioning makes semantic versioning less meaningful A major version bump for a module could signal a breaking change, or it could just be due to the packages it's locked to having had a breaking change

humanrebar 10y ago
A breaking change in your dependencies is a breaking change for you. If it weren't, minor version upgrades would cause you to pull in incompatible dependencies. This is why keeping your dependency list as tiny as possible is imperative.
- mikewhy 10y ago
  Wait, I'm confused. Say I'm the author of a library. Some of my dependencies had breaking changes, but they didn't affect the users of my library, as it's handled in some method. Should that be a new major version of the library?
  - humanrebar 10y ago
    The sensible default answer with no context is: bump your major version as well. The more nuanced answer is that it depends on your packaging system and your language runtime. If either cannot handle more than one minor version of a dependency at the same time, you need to bump a major version. The problem is that the code that uses your library might also indirectly be using that dependency, but pinned to a different major version. This means that the application is broken even though the breaking changes aren't used by your library. To illustrate: apple-1.0 => banana-1.0 => carrot-1.0 => broccoli-1.0 => carrot-1.0 Say, as the maintainer of banana-1.0 want bug fixes in carrot-2.0, so you pull it in and bump your minor version. And then an application updates it dependencies. apple-1.1 => banana-1.1 => carrot-2.0 => broccoli-1.3 => carrot-1.1 In some, though not many, systems, you can pull in two versions as if they were different libraries. But in almost all, you get a dependency conflict and apple will be broken. Even if you can juggle two dependencies of the same library, you need to make sure there wouldn't be any logic changes that would break the system or even corrupt data (!). Anyway, it's simpler to be conservative and bump the major version. Yes, that can be a pain. But, again, it's good to keep your dependency list small or at least very boring to keep that pain to a minimum.

humanrebar 10y ago

A breaking change in your dependencies is a breaking change for you. If it weren't, minor version upgrades would cause you to pull in incompatible dependencies. This is why keeping your dependency list as tiny as possible is imperative.

mikewhy 10y ago
Wait, I'm confused. Say I'm the author of a library. Some of my dependencies had breaking changes, but they didn't affect the users of my library, as it's handled in some method. Should that be a new major version of the library?
- humanrebar 10y ago
  The sensible default answer with no context is: bump your major version as well. The more nuanced answer is that it depends on your packaging system and your language runtime. If either cannot handle more than one minor version of a dependency at the same time, you need to bump a major version. The problem is that the code that uses your library might also indirectly be using that dependency, but pinned to a different major version. This means that the application is broken even though the breaking changes aren't used by your library. To illustrate: apple-1.0 => banana-1.0 => carrot-1.0 => broccoli-1.0 => carrot-1.0 Say, as the maintainer of banana-1.0 want bug fixes in carrot-2.0, so you pull it in and bump your minor version. And then an application updates it dependencies. apple-1.1 => banana-1.1 => carrot-2.0 => broccoli-1.3 => carrot-1.1 In some, though not many, systems, you can pull in two versions as if they were different libraries. But in almost all, you get a dependency conflict and apple will be broken. Even if you can juggle two dependencies of the same library, you need to make sure there wouldn't be any logic changes that would break the system or even corrupt data (!). Anyway, it's simpler to be conservative and bump the major version. Yes, that can be a pain. But, again, it's good to keep your dependency list small or at least very boring to keep that pain to a minimum.