On Fri, Apr 8, 2016 at 1:35 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On 2016-04-08 13:26, Luca De Feo wrote:
>>
>> This is something that should only happen at major version bumps, if ever.
>
>
> That's easily solved: the next stable release of Sage should be Sage 8, then
> Sage 9 and so on...
>
> We do have a 1-year deprecation policy, but of course it's not enforced (and
> I wouldn't know how to enforce that). If the author and reviewer of a ticket
> don't care about deprecation, then stuff will break.

Deprecation really should be enforced by policy.  Use a decorator when
marking a function or class (or specific feature thereof) deprecated,
and include in the decoration the *version* in which it was marked
deprecated.

When working on prepping releases search for code that has been marked
deprecated for a long time and remove it.  But definitely not too
soon.  Don't advertise an interface as stable and then move it around
between X.Y releases without a deprecation process.  Sage-the-library,
or much of it, is grown up enough (in terms of stability) that it
should definitely be doing this.  Enforcing this should be part of the
release manger's job (but everyone should help by being vigilant).

Best,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to