Le 09/02/2014 14:56, Luc Maisonobe a écrit : > 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.
I have added an ignore files for the changes discussed previously. I had to upgrade clirr to 2.6.1 otherwise the ignore file generated errors due to <https://jira.codehaus.org/browse/MCLIRR-52>. The report now displays 4 errors, which are false positive. In these 4 cases, clirr says a method argument changed to a superclass, but in fact the method is new and the former method with the former signature is still available in the same class. One strange thing is that if I attempt to put an entry in the ignore file, instead of reducing the number of errors it increases it and the same error appears several time in the report. Another strange thing is that the problem appears for method toSubSpace, but not for method toSpace despite the same type of changes have been performed for both methods (i.e. a new method added and the former one preserced for compatibility). I have also added warning in the javadoc (at package level and classes level) to identify the interfaces that users should not implement themselves and that may change. best regards, Luc > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
