commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] LocalizedFormats.ALPHA and BETA no longer used
Date Thu, 31 May 2012 08:17:21 GMT
Le 31/05/2012 08:23, Sébastien Brisard a écrit :
> Hi,
> 
> 2012/5/27 Sébastien Brisard <sebastien.brisard@m4x.org>:
>> Hi,
>>
>> 2012/5/27 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>>> Le 27/05/2012 16:25, Jochen Wiedmann a écrit :
>>>> On Thu, May 24, 2012 at 8:41 PM, Luc Maisonobe <Luc.Maisonobe@free.fr>
wrote:
>>>>> Le 24/05/2012 21:27, Sébastien Brisard a écrit :
>>>>>> Hi,
>>>>>> commit 1342404 solves MATH-791. It turns out that
>>>>>> LocalizedFormats.ALPHA and BETA are no longer used. I wanted to remove
>>>>>> them, but that breaks the compatibility. How should we do that
>>>>>> cleanly?
>>>>>
>>>>> Just remove the entries from the enum and temove the corresponding entry
>>>>> in the translation properties file.
>>>>
>>>> Why remove them at all? I understand the desire, it meets my sense for
>>>> clean code. But I learned to fight against these desires from time to
>>>> time.
>>>
>>> These parameters are mainly for internal use, we don't consider them as
>>> part of the public API. As we remove their internal use, it seems good
>>> to be consistent and remove everything at once.
>>>
>> I fully agree.
>>
>>>
>>> Do you have an idea about another use that could justify we retain them ?
>>>
>> It's probably just as well to restore these constants if we find a use
>> for them at a later point (that would be trivial).
>>
>> So, do we agree that these constants should go? How should I proceed?
>> The clean way (deprecation in 3.1, and complete removal in 4.0), or
>> the brutal way (complete removal in 3.1) ?
>>
>> Best regards,
>> Sébastien
> 
> I've created MATH-796 for this issue. My favoured option would be
> complete removal in 3.1, together with explanations in the release
> notes (as suggested by sebb) to account for clirr's complaints.

Yes, this seems a good way to go.

Luc

> Sébastien
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message