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 11:17:24 GMT
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


Gilles


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


Mime
View raw message