Florent Hivert wrote:
>>>> Of course, when writing code, we have no idea what date the next  
>>>> release
>>>> would be, and sometimes are mistaken about the release that the patch
>>>> will be included in as well.  How should we take care of this
>>>> patch-updating problem?
>>> I've been lazy to raise this problem on the lists. Sorry for that.
>>>
>>> Is this really a problem a warning tells that a function is  
>>> deprecated since
>>> version 3.1 whereas it was really deprecated in version 3.2 ?  If  
>>> yes a
>>> possible solution is the following:
>> It's deprecated as soon as a decision is made.
> 
> So should I understand that you even don't want to mention any sage version in
> the deprecation warning. IE you'd rather have
> 
> 
> sage: Partition([2,1]).boxes()
> DeprecationWarning: (Since 2009-09-10) The function bar is removed.


 From the point of view of the user, having a date that is not the date 
of a sage release seems a bit insulting; "you mean to tell me that two 
weeks ago, you deprecated some functionality I use, but didn't tell me 
until the next Sage release?".  I think I'd rather have the deprecation 
based on Sage version number (and corresponding date).  I don't know of 
any other software that backdates deprecations to the time the patch was 
merged.

In fact, most software that I've seen dates deprecation warnings *only* 
by version, and leaves the dates up to the user.

Of course, most software that I've seen also doesn't have releases every 
3-4 weeks.

Jason


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to