commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <...@spaceroots.org>
Subject Re: [Math] Next release: 4.0 or 3.5 ?
Date Thu, 08 Jan 2015 14:20:21 GMT
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 <gilles@harfang.homelinux.org>
>> wrote:
>>
>>> On Thu, 8 Jan 2015 01:25:42 +0000, sebb wrote:
>>>
>>>> On 8 January 2015 at 00:43, Gilles <gilles@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>>> On Wed, 7 Jan 2015 14:46:19 +0000, sebb wrote:
>>>>>
>>>>>>
>>>>>> On 7 January 2015 at 08:23, luc <luc@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message