On Thu, 29 Feb 2024 at 00:13, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi sebb, > > On Wed, 28 Feb 2024 at 23:48, sebb <seb...@gmail.com> wrote: > > > Remark that I am talking about moving whole packages to new artifacts. > > > > Will these packages be renamed? > > > > If not, then I don't see how you can prevent possible class duplication. > > Do they need to be renamed? This breaks backward compatibility.
Yes, to avoid class chaos. > A user could have duplicated classes if he has an old > `commons-compress` 1.26.0 together with a newer > `commons-compress-core`, My point exactly. > 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. > Since an example is better than a thousand words I submitted a PoC on > how to split Commons Compress: > > https://github.com/apache/commons-compress/pull/490 > > A simple `mvn clean verify` succeeds. I just need to smoothen out the > CI's failures. A single build cannot prove that the solution works in the Maven environment with multiple releases present. > 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