commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Next release: 4.0 or 3.5 ?
Date Thu, 08 Jan 2015 13:55:05 GMT
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?
>>>>>
>>>>> 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.

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.

Gilles


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


Mime
View raw message