> Do anyone who voted A understand that this is equivalent to a vote for > changing the package name of a library even if we only added a few classes > to that package without breaking the compatibility of any previously > existing classes?
I wonder this too. This list has multiple explanations for why changing the namespace goes against XML usage and intentions. Your package name example is good. A couple more oversimplified not-fully-accurate ways to think about it: 1. The namespace is like a product name and the version is its release. Should we change the product name upon release? 2. The namespace is like a store name and the version is its products for sale. Should we change the store name when adding or removing the store's products for sale? On Sat, Apr 4, 2026 at 12:02 PM Gary Gregory <[email protected]> wrote: > I feel the same, from the peanut gallery: Elliott explained the problems > with the change but I don't think the consequences have been understood. > > 2c, > Gary > > On Sat, Apr 4, 2026, 12:45 Martin Desruisseaux via dev < > [email protected]> > wrote: > > > Hello Chris > > > > Le 04/04/2026 à 17:21, Chris Lafren a écrit : > > > > > I don't understand where that "been there for 4 years" argument comes > > > from. > > > > > I don't know neither, I just repeated what I saw on the mailing list, > > but never verified. > > > > The thing that worry me a little bit is that I don't really know how > > well understood the technical issues were before the vote took place. Do > > anyone who voted A understand that this is equivalent to a vote for > > changing the package name of a library even if we only added a few > > classes to that package without breaking the compatibility of any > > previously existing classes? Or are we victims of the fact that XML > > namespaces often have a year or version number in their URL, which gives > > a psychological incentive to increase that number even if we should not? > > > > If there is no answer to above question, I guess that I have to assume > > that the vote was an informed choice in favor of preserving established > > Maven 4 practice of the last few years, and that it was considered by > > the majority as more important than creating technical debt. > > > > Martin > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
