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 11:42:35 GMT
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 a
>>>>    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.


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

View raw message