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 Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
