On Wed, Nov 24, 2010 at 10:34 AM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote:
> Hello. > > > If you break compatibility, then the advisable thing to do is change > > the package name (and artifactId, etc.). Now, if we can be almost > > certain that there would be no case that you wouldn't have a situation > > come up where two different, incompatible versions of math would be > > required on the classpath (you guys can't think of a situation where > > one project might use two different libraries that use two different > > version of math?), > > Wouldn't it mean that at least one of the two libraries is not an active > project? Otherwise I'd think they would benefit from upgrading. > Not necessarily. The Orekit example that Luc gave is a good one. A project could use [math] directly and be very actively maintained and needing the 3.0 features / fixes, but depend on an earlier version of Orekit that depends on math 2.1. Orekit itself (or whatever other immediate dependency) may not have cut a release changing its internal use to 3.0. At that point, the project using both [math] directly and Orekit needs to have both versions available. Since dependency on the 2.1 code is encapsulated in Orekit, there is no need for the [math] versions to be compatible for the app to work. > > Another aspect is that, by making it possible, we would encourage "lazy" > users to not upgrade, and would thus loose them as "testers" of the new > releases. > > It's nice to help users[1] but we should not forget that we can be > confident > in the code only if it is largely used. Bugs in the "linear" package went > unnoticed until a real-world code stressed it. > So, I'm not sure that, at this point, we can afford "lazy" users ;-) [I'm > playing the devil's advocate here.] > As I said, the use case driving the need for the package name change is really beyond users' control, so I am +1 on the package name change for 3.0 Phil > > > [...] > > > Gilles > > [1] I would be the first to have a little less work as a result of the name > change. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
