Jörg Schaible a écrit : > Phil Steitz wrote: > >> Niall Pemberton wrote: >>> -1 >>> >>> IMO breaking compatibility should be decided on a case-by-case basis >>> for components. For the widely used variety such as lang, logging, >>> collections etc then I agree lets avoid jar-hell and not do it. But >>> for other components that are not so widely used then such as Math I >>> think its better to minimize the pain of upgrading for the user.' >>> >> I keep going back and forth on this. I agree strongly with the >> "minimize the pain" objective, which is why I have been pushing to keep >> the incompatible changes to a minimum (which we have largely >> accomplished). For me personally (with user hat on) it would be easier >> if the package name did not change. I guess what it comes down to is >> how many users will actually experience the "jar hell" scenario with >> [math] vs. *every* user having to change all of their imports to upgrade. >> >> Sorry to do this, but on reflection, I think no change is likely to be >> the pain-minimizing alternative, so I am changing my vote to -1. > > Guys, you know what you do? Actually it was already reported to the list > that some projects already faced the incompatibility problem even with
One funny fact is that in the project for which problems occurred the team prefers to keep the old name, despite they have already been bitten by a 1.2 vs 2.0 jar issue. I agree with both Niall and Phil that few users will be affected. I guess most people using [math] do it directly, not from several dependencies paths. The project I cited does this and the jar issue was fixed easily once it has been spotted two different versions were in the classpath. > math. With you veto you simply tell them "it's your problem, but we don't > have a solution for it either". That's what I would call a complete show > stopper. Both options can be considered rude for users. Some would not understand why the name is changed and complain, some would not understand why we would not prevent jar hell and complain too. There are no good solutions, let's hope OSGi will become mainstream before math 3.0. > > If somebody really want to migrate to newer math, he can simply search and > replace every org.apache.commons.math to org.apache.commons.math2 and will > then face the locations in the code where he has actually to adjust > something. However, he must not fear that due to his switch some other 3rd > party dep will no longer operate. With your scenario, he's simply out of > the game. This is not as simple. There are incompatible changes. Most changes are not very difficult to understand and correspond to simple packages reorganizations or renaming. However, there are also a small set of deep modifications like the new decomposition and the reorganized optimization frameworks. Users of these packages will have to learn the new API and change their code, regardless of the name of the top level package being changed or not. Luc > > - Jörg > > > --------------------------------------------------------------------- > 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
