Well these fragile programs are also often setting an "ignore any namespace error or even read" configuration so not sure how relevant it is to consider them - and trust me I did write a lot using all possible options, DOM, stax, plain string parsing.
And once again, the whole goal to create a 4.1.0 is to enable to break - and we did, so think we passed that stage of we want to maintain compatibility and we already entered the fact we want to respect a version so these programs will need to adapt in general (at least just the parent parsing for ex). That said your point is very valid and we should make it more obvious, scripts will stay fragile cause they are often quick glue code, but it will be more obvious and they can add a few validations to fail more obviously probably. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le sam. 28 mars 2026 à 22:39, Fabrice Bauzac <[email protected]> a écrit : > Le sam. 28 mars 2026 à 21:54, Romain Manni-Bucau > <[email protected]> a écrit : > > > how changing the tag definitions doesn't break them? > > Indeed, if a script is looking at good old > /project/dependencies/dependency/artifactId, > > while the format changes to some short form like: > > #+begin_src xml > <dependency>groupid:artifactid:version</dependency> > #+end_src > > Then the script will break because it will not find <artifactId> > within <dependency>. If such a breaking change is made on the format, > we won't save those programs. > > However, for programs that are not affected by this format change, > it's bad to change the namespace and break them gratuitously. > > We generally don't want to break APIs, and we prefer to just extend > them and be mostly backwards compatible, even though from time to time > there is breakage. That's what I want to say here regarding evolving > the pom format without gratuitously breaking the programs that use it. > > > intent of changing the version (namespace or modelversion) is to enable > > scripts or apps to handle it cleanly and not in a hacky way. > > Yes, many programs will learn about newer evolutions of the pom format > and become able to support old and new pom formats. For me that can > be done through <modelVersion> information, which has the advantage of > not breaking 100% of the existing programs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
