On Mon, Dec 11, 2023 at 6:20 PM Robert Middleton <rmiddle...@apache.org> wrote:
> add new method/class = minor version bump > change/fix behavior without adding new method = patch > I think this is where we have different ideas. Robert, could you elaborate on *"change/fix behavior without adding new method"*, please? For instance, does this cover the following changes? - Upgrading a dependency whose patch version is bumped (no behavior change on the parts we use the dependency) - Upgrading a dependency whose minor version is bumped (no behavior change on the parts we use the dependency) - Upgrading a dependency whose major version is bumped (no behavior change on the parts we use the dependency) - Upgrading a dependency whose major version is bumped (no behavior change on the parts we use the dependency, though the runtime requirements of the dependency has changed, e.g., started requiring Java 17 instead of Java 8, etc.) - `sum(a,b)` has changed from `a+b` to `a-b` (behaviour change, no new method) - `sum(a,b)` has started using GPUs (no change visible to the user, though substantial implementation change) My point is, it is difficult to draw a line and the gray area is pretty large. Hence, I propose a very simple resolution rule for minor-vs-patch that doesn't have room for ambiguity: Is it only a selected set of fixes and nothing else? Then it is a `patch` bump, otherwise everything else is a `minor` bump.
