Le 09/02/2014 13:26, Thomas Neidhart a écrit : > 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 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. > > Clirr does not yet support annotations for marking ignored differences, > but we can specify them in a separate configuration file: > > http://mojo.codehaus.org/clirr-maven-plugin/examples/ignored-differences.html
Thanks Thomas, I'll have a look at this in a few hours. Luc > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
