On Thu, Apr 24, 2008 at 6:45 AM, sebb <[EMAIL PROTECTED]> wrote: > 2008/4/24 <[EMAIL PROTECTED]>: > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
