commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <>
Subject Re: [math] Release planning for 3.3
Date Sun, 09 Feb 2014 12:26:29 GMT
On 02/09/2014 12:42 PM, Thomas Neidhart wrote:
> On 02/09/2014 12:31 PM, Luc Maisonobe wrote:
>> Le 09/02/2014 00:40, Thomas Neidhart a écrit :
>>> On 02/08/2014 07:30 PM, Phil Steitz wrote:
>>>> On 2/8/14, 9:25 AM, Thomas Neidhart wrote:
>>>>> Hi,
>>>>> I think we are very close to releasing 3.3.
>>>>> Looking through the issues, the following should/need to be resolved:
>>>>> TN (in progress):
>>>>>  * [MATH-1071] Improve genetic algorithms section in userguide
>>>>>  * [MATH-1061] Improve filter section in userguide
>>>>>  * [MATH-749] Convex Hull algorithm: almost finished
>>>>> Others:
>>>>>  * [MATH-1065] EnumeratedRealDistribution.inverseCumulativeProbability
>>>>>    should be fixed imho, I outlined an algorithm but would like to have
>>>>>    some feedback
>>>> See comment on ticket.
>>>>>  * [MATH-923] Kohonen's SOFM: can it be considered finished?
>>>> You mean releasable :)
>>>> +1 - I like this code.  The question is really are we OK with the
>>>> API and I don't think we will be able to definitively answer that
>>>> until we get it out and used, so I would say release it now,
>>>> assuming Gilles and others agree.
>>> me too.
>>> Maybe it is easier to take the risk now as the next foreseen release is
>>> 4.0 and we can more easily correct any mistakes.
>>>>>  * [MATH-928] Alternative approach to matrix implementations:
>>>>>    postpone to 4.0?
>>>> +1
>>>>>  * [MATH-990] Improve performance of MathArrays.sortInPlace:
>>>>>    finished for 3.3?
>>>> +1
>>>>> Other issues to be discussed:
>>>>>  * [MATH-1008]
>>>>>    a new package has been created o.a.c.m.fitting.leastsquares which
>>>>>    contains some interface for the new fluent API but they are also
>>>>>    used elsewhere so I guess it would be more logical to put them in
>>>>>    more general place, e.g. WithMaxEvaluations should be moved to
>>>>>    o.a.c.m.optim. WDYT?
>>>> +1
>>>>>  * Clirr errors in o.a.c.m.geometry and sub-packages
>>>>>    there are now ~30 errors wrt changed interfaces due to some
>>>>>    refactoring. What shall we do about them?
>>>> Need to decide which are really problems and either revert or doc
>>>> them somehow.
>>> I think some are harmless (e.g. changed parameter type from Vector to
>>> its superclass Point), but others seem to be not bc.
>> We have very quickly discussed about it some weeks ago. I have done my
>> best to avoid incompatibilities, and where incompatibilities were
>> unavoidable, there are in fact mostly theoretical.
>> Concerning the parameters changes from Vector to Point, it is in fact
>> false positive from Clirr. The methods signature have been changed at
>> interface level, but the new methods are more general than the previous
>> ones, so at source level, there is still compatibility. At binary level,
>> in fact the former methods are still there with the Vector signature,
>> they have simply been pushed down to implementation level. Therefore,
>> the implementation classes have both signatures available.
>> Concerning the other changes, they correspond to changes at interface
>> level in the partitioning package. Theses interfaces are *not* intended
>> to be implemented by users, and in fact even in the library itself, they
>> have been implemented only by myself, and I have updated all the
>> implementation classes. These interfaces are there *only* as a way to
>> share common code for BSP tree (which is complex code). I would have
>> liked to have them more private, but private inheritance is not allowed
>> in Java. So I really think updating these interfaces even in a minor
>> release is possible, and I explicitly ask for this now. I *need* this
>> and it won't break any real application, as nobody implemented these
>> private interfaces.
> Hi Luc,
> I now remember this discussion, and I am ok with that. We need to add a
> very clear paragraph in the release notes stating this.
> I guess making these respective interfaces/classes package private in
> the first place would not have solved it either as they are also used
> from other packages?
> Maybe we should really think about adding some annotations that clearly
> mark certain classes as internal and we do not guarantee BC between
> minor releases for them.

Clirr does not yet support annotations for marking ignored differences,
but we can specify them in a separate configuration file:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message