commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: svn commit: r651244 - in /commons/proper/math/branches/MATH_2_0/src/java/org/apache/commons/math/linear: BigMatrixImpl.java RealMatrixImpl.java
Date Thu, 24 Apr 2008 20:19:29 GMT
On Thu, Apr 24, 2008 at 6:45 AM, sebb <sebbaz@gmail.com> wrote:
> 2008/4/24  <luc.maisonobe@free.fr>:
>
> > This change is a little weird.
>  >
>  >  We discussed about this field back in january
>  >  (http://markmail.org/message/45y6znvvg2ucauwa) and decided to deprecate it
>  >  before changing it to private static.
>  >
>  >  We forgot to mark it deprecated while releasing 1.2.
>  >
>  >  Since 2.0 will introduce other incompatible changes, I thought it was time to
>  >  make the change and went ahead with the modification. I feel uncomfortable with
>  >  this though, because users have not been warned about this (however, I'm not
>  >  sure anybody relied on the availability of this protected field).
>  >
>  >  There is another change that bother me: we did not deprecate either the
>  >  UnivariateRealSolverFactory class and did not replace it by setter injection in
>  >  1.2, as we have done for other algorithms.
>  >
>  >  Do you think we should:
>  >   1) revert the change and go back to a protected field, not
>  >     forgetting to mark it as deprecated and removing it in 3.0
>  >   2) go ahead and only apologize about forgotten deprecation mark
>  >     (and also replace UnivariateRealSolverFactory in the same move)
>  >   3) do a 1.3 release only in order to add the forgotten deprecation
>  >
>  >  Choice 1 is the most conservative one, but means we will keep dirty code for a
>  >  long time. Choice 2 is my personal preference, it is rather rude but I think we
>  >  made a mistake and have to assume it. Choice 3 seems realistic only if we
>  >  release 1.3 very soon to let users take these deprecations onto account and wait
>  >  some time before 2.0, I don't like it because 2.0 is really badly needed for the
>  >  features it will bring.
>
>  Upgrading from 1.2 to 2.0 is a major version change - seems to me that
>  users should expect such changes.
>  So long as the change is clearly documented, I don't see a problem, so
>  I would support choice 2.
>
>

+1 for option 2.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message