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? >>>> >>>> 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. >>>> >>>> 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. >> >> > 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 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. Gary > > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
