On 27 May 2011 23:39, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Fri, May 27, 2011 at 6:04 PM, sebb <seb...@gmail.com> wrote: >> On 27 May 2011 16:46, <n...@apache.org> wrote: >>> Author: nick >>> Date: Fri May 27 15:46:11 2011 >>> New Revision: 1128371 >>> >>> URL: http://svn.apache.org/viewvc?rev=1128371&view=rev >>> Log: >>> VALIDATOR-253 - Change the groupId for 1.4 to be org.apache.commons to >>> match the new commons pattern, and add a redirect pom that can be used to >>> help migration >>> >>> Added: >>> commons/proper/validator/trunk/redirect.pom >>> Modified: >>> commons/proper/validator/trunk/pom.xml >> >> Unfortunately this won't work. >> >> Redirect POMs only work if there is a dependency on that particular >> version, and Maven Central does not allow previous versions to be >> updated to add redirect POMs. Even if it did, it would take some while >> for local workspaces to retrieve the new details. >> >> If an application depends on Validation 1.3 and Validation 1.4 (via >> different transitive dependencies) then it will get copies of both >> versions. >> >> The only safe solution is to change the package name as well. >> >> Or don''t fix the groupId until you have to change the package name >> for some other reason, e.g. API breakage. > > Validator has broken binary compatibility in previous releases and we > never had a single complaint. IMO this component falls into a > different category than something like lang or io since it not a low > level library thats widely depended on. Usually its used either thru' > a framework such as Struts or JSF or as a direct dependency. > > So IMO if we want to change the groupid or make small incompatible > changes it would be OK.
Changing the groupId without changing the package name can result in two copies of the library on the classpath, which is much harder to debug than a binary API change. It's not essential to change the groupId, so why run the risk? BTW, the current code is binary compatible with 1.3.1. > Niall > > --------------------------------------------------------------------- > 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
