On Thu, 29 Feb 2024 at 09:53, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi sebb, > > On Thu, 29 Feb 2024 at 10:25, sebb <seb...@gmail.com> wrote: > > > but dependency management can be used to > > > prevent version mismatches. > > > > What dependency management is that? Does Maven manage this? > > Seems like users would be forced to use extra controls to ensure only > > comaptible combinations of artifacts were used. > > Maven users would be forced to add a new `commons-compress-bom` > artifact (in my PR) to their dependency management. As far as I know > other build systems (Gradle, Coursier, probably Apache Ivy) resolve > version conflicts with a "highest version wins strategy", so the > change will be a no-op for them.
Are you sure about that? What if a component specifies a version range? > Yes, this change might require a developer to supervise the upgrade, > so it might require a major version bump to drive their attention. > However personally I find it less problematic than having half the > dependency stack using `o.a.c.compress` and half of it using > `o.a.c.compress2`. Agreed that might be harder to change automatically. But my solution in this case would be a complete package/Maven coord break. A one-off global edit, but no worries about missing dependency restrictions. > The necessity to align the versions of a multi-module project is > something many users are aware of (and the others use Spring Boot > dependency management ;-) ). Or they expect Maven to take care of version management for them. > Piotr > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
