Hi all, It seems several mials piled up before I can answer, so I'll try to catch up in one post.
Le 08/01/2015 14:55, Gilles a écrit : > On Thu, 8 Jan 2015 07:53:06 -0500, Gary Gregory wrote: >> On Thu, Jan 8, 2015 at 6:17 AM, Gilles <gil...@harfang.homelinux.org> >> wrote: >> >>> On Thu, 8 Jan 2015 01:25:42 +0000, sebb wrote: >>> >>>> On 8 January 2015 at 00:43, Gilles <gil...@harfang.homelinux.org> >>>> wrote: >>>> >>>>> On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote: >>>>> >>>>>> >>>>>> On 7 January 2015 at 08:23, luc <l...@spaceroots.org> wrote: >>>>>> >>>>>>> >>>>>>> Le 2015-01-06 23:13, Gilles a écrit : >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi. >>>>>>>>> >>>>>>>>> Do we head towards 4.0, starting to implement the dreaded >>>>>>>>> breakings? ;-) >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> +1, +1, +1, +1 !!! >>>>>>> >>>>>>> To be serious, yes, we are really stuck by now and several pending >>>>>>> changes should be done. We talked about fluent API for optimizers >>>>>>> and it was too much too squeeze without breaking API. I attempted >>>>>>> the same for ODE, and here again it was postponed as it touched >>>>>>> user level interfaces. >>>>>>> >>>>>>> I would even say that we should from the beginning change the top >>>>>>> level package name to 4.0 so users can test earlier the changes as >>>>>>> we prepare the next version, using only one feature at a time and >>>>>>> preserving the older release for the other features. >>>>>>> >>>>>> >>>>>> >>>>>> That needs to be done carefully to avoid creating jar hell. >>>>>> What exactly are you proposing here? I was proposing to change both the top level package to a.o.c.math4 and to change the maven coordinates, so both artifacts can be used in parallel for users who want to switch smoothly. They could use some stuff from math3 and other stuff from math4. All stuff from math4 would only depends on math4, i.e. both jars are independent. >>>>>> >>>>>> Are you referring to SNAPSHOTs only (in which case caution is only >>>>>> advisable)? >>>>>> >>>>>> If you are proposing to release jars with the new package name, then >>>>>> this needs to be done in a separate jar with new Maven coords. Yes. >>>>>> >>>>>> It would be possible to gradually add more packages to the new jar as >>>>>> the original ones are converted. >>>>>> >>>>> >>>>> >>>>> IIUC, we'd change the top-level package in "trunk". >>>>> [Not releasing anything. Beta-testers would need to check out (i.e. >>>>> "clone") the source repository and compile the library by themselves.] >>>>> >>>>> >>>> If you only used the new package on the updated API it would be more >>>> obvious what was the proposed new API and what was old. Please no. This would be a nightmare to maintain. We do have some low level stuff used by our public API. What if we need to change a low level for the need of math4 (say add a new exception). We would end up with duplicating again and again. We already have some features that are in *3 different implementations* in math3. My goal here is more to remove old stuff than to pile up again. >>>> >>>> >>> Pushing this further, couldn't we provide two top-level packages already >>> in a backward-compatible release? I.e. in, say, CM 3.5, there would be >>> o.a.c.math3 -> all the existing code + bug fixes >>> o.a.c.math4 -> redesigned bits + new features No. There are low level stuff that would need to be duplicated in both hierarchy, duplicating again (think exceptions, think all the utilities). We are *not* able anymore to maintain 4.0/3.x compatibility and you would like us to expand it further within the library. I would veto such a change. >> >> >> This sounds like a recipe for jar hell. We have to think about a large >> app >> with dependencies on both math3 and 4, meaning both jars are on the CP >> and >> in use. > > Why would someone keep both JARs in the CP, if one contains everything? > A problem I could see is that classes from math3 could be picked from the > old JAR whereas some bug would have been fixed in the new JAR only. > The contents of both JARs would be compatible (the same actually), so there > is no hell. Jar hell is when you get cross dependencies. By completely cutting the link between 3.x and 4.0, I precisely want to avoid jar hell. If a new feature (or a redesigned feature) is in 4.0, then users who want to use it would have to get a dependency on math4. These people could have at the same time another unrelated dependency to math3 for other features. Math4 would not know anything about math3. The user would then be able to update the top level application smoothly, starting with one or two packages, replacing some math3 by some math4, until there are no math3 dependencies anymore. best regards, Luc > > Gilles > > > --------------------------------------------------------------------- > 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
