You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2012/12/15 07:03:14 UTC
[math] missing deprecations?
The classes in .optimization.fitting seem to have been duplicated /
moved to .fitting, but the originals are not deprecated (though some
methods in them are). Shouldn't we deprecate the original classes?
Also, @since for the moved versions should be 3.1, correct?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] missing deprecations?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/15/12 8:50 AM, Phil Steitz wrote:
> On 12/15/12 4:07 AM, Gilles Sadowski wrote:
>> On Fri, Dec 14, 2012 at 10:03:14PM -0800, Phil Steitz wrote:
>>> The classes in .optimization.fitting seem to have been duplicated /
>>> moved to .fitting, but the originals are not deprecated (though some
>>> methods in them are). Shouldn't we deprecate the original classes?
>> Yes. In fact, all the classes under "o.a.c.m.optimization" are deprecated;
>> I intended to mark them as such, but somehow got distracted by other
>> things... ;-)
>> Thanks for the reminder.
>>
>>> Also, @since for the moved versions should be 3.1, correct?
>> It depends what is meant by "@since"... Is it the appearance of a new
>> feature (algorithm or data structure), or the actual naming or renaming
>> of a class or method? [There are arguments for each, but both cannot be
>> accomodated with a single tag.]
> Good point. I would say leave the moved version @since tags as is.
>> In the former case, the answer to your question would be no since it is a
>> only a refactoring of existing features.
>>
>> In the latter, we'd have a problem: many "@since" tags are 1.2, 2.0, ...
>> whereas they should _all_ be 3.0 because of the package name change (from
>> "o.a.c.math" to "o.a.c.math3").
>> Since that had not been a blocker for a major release, I propose that we
>> postpone the resolution of this situation to the next release (opening a
>> JIRA report) or until we are sure how to best use "@since" must be used in
>> CM.
> I need a couple more hours to review and fill in the rest of the
> missing ones.
Done.
Phil
>
> Phil
>
>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] missing deprecations?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/15/12 4:07 AM, Gilles Sadowski wrote:
> On Fri, Dec 14, 2012 at 10:03:14PM -0800, Phil Steitz wrote:
>> The classes in .optimization.fitting seem to have been duplicated /
>> moved to .fitting, but the originals are not deprecated (though some
>> methods in them are). Shouldn't we deprecate the original classes?
> Yes. In fact, all the classes under "o.a.c.m.optimization" are deprecated;
> I intended to mark them as such, but somehow got distracted by other
> things... ;-)
> Thanks for the reminder.
>
>> Also, @since for the moved versions should be 3.1, correct?
> It depends what is meant by "@since"... Is it the appearance of a new
> feature (algorithm or data structure), or the actual naming or renaming
> of a class or method? [There are arguments for each, but both cannot be
> accomodated with a single tag.]
Good point. I would say leave the moved version @since tags as is.
>
> In the former case, the answer to your question would be no since it is a
> only a refactoring of existing features.
>
> In the latter, we'd have a problem: many "@since" tags are 1.2, 2.0, ...
> whereas they should _all_ be 3.0 because of the package name change (from
> "o.a.c.math" to "o.a.c.math3").
> Since that had not been a blocker for a major release, I propose that we
> postpone the resolution of this situation to the next release (opening a
> JIRA report) or until we are sure how to best use "@since" must be used in
> CM.
I need a couple more hours to review and fill in the rest of the
missing ones.
Phil
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] missing deprecations?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Fri, Dec 14, 2012 at 10:03:14PM -0800, Phil Steitz wrote:
> The classes in .optimization.fitting seem to have been duplicated /
> moved to .fitting, but the originals are not deprecated (though some
> methods in them are). Shouldn't we deprecate the original classes?
Yes. In fact, all the classes under "o.a.c.m.optimization" are deprecated;
I intended to mark them as such, but somehow got distracted by other
things... ;-)
Thanks for the reminder.
> Also, @since for the moved versions should be 3.1, correct?
It depends what is meant by "@since"... Is it the appearance of a new
feature (algorithm or data structure), or the actual naming or renaming
of a class or method? [There are arguments for each, but both cannot be
accomodated with a single tag.]
In the former case, the answer to your question would be no since it is a
only a refactoring of existing features.
In the latter, we'd have a problem: many "@since" tags are 1.2, 2.0, ...
whereas they should _all_ be 3.0 because of the package name change (from
"o.a.c.math" to "o.a.c.math3").
Since that had not been a blocker for a major release, I propose that we
postpone the resolution of this situation to the next release (opening a
JIRA report) or until we are sure how to best use "@since" must be used in
CM.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org