Alex Ghitza wrote: > > Dear sage-devel, > > > A while back we decided that we shouldn't just randomly break users' > existing code even if the reason is very good (e.g. there are 20 names > for the exact same thing, and 19 of them are just bad, or we want to > change to a better convention for something). The idea was that > features, names, etc. should not simply be removed, but they should be > deprecated; so they would continue to work just as before for a while, > but they would display a DeprecationWarning whenever they are used. I > guess the idea is that the user would eventually get tired of seeing > the warning and finally switch to the new and improved notation, > convention, whatever. > > There was some discussion of the length of time for which we should > keep deprecated features around before finally throwing them out, but > as far as I know there was no clear decision on this (and the > Developer Guide doesn't mention anything about this). > > Can we decide on something? I don't really have strong feelings about > this, but given some of the issues that transpired in the thread about > stable/conservative versions of Sage, I would tend to pick something > like 12 months (which for Sage counts as rather long-term). Of course > this wouldn't have to be set in stone and we could revisit the > decision in 20 years once/if the pace of development has slowed down. > To me, a year is FAR too short. Mathematica makes a major release about once every two years, and a semi-major one every 6-12 months. There are plenty of people using older versions of that. If Sage wants to make a viable alternative to Mathematica, it needs to keep deprecated functions a lot longer than a year. I know WRI do - I'm also aware they break backwards compatibility some times.
I think 10 years would be best. Any less than 5 is asking for trouble. Sure Sage makes a new release every couple of weeks, but as we see from recent discussions, not everyone wants to update every couple of weeks. > Another question is how we can efficiently keep track of deprecated > things. Having thought about this for a whole 3 minutes: we could set > up a new component on trac, called "deprecation"; each time a patch > deprecating something gets a positive review, the patch author should > create a new deprecation ticket, which could contain a time stamp in > its title, and refer to the original ticket. Then bored/conscientious > people could comb through these deprecation tickets once in a while > and, once the time is up, actually remove the deprecated stuff. As for your idea of adding something to trac, I would agree with that. I have often seen files where there are references to something can be removed in a couple of months, but it is there years later. I do not know if it is possible, but I wish one could select more than one thing in trac. i.e. some issues might be related to deprication on Solaris. Does that go into deprecated, or Solaris? Sometimes I've found things that affect Solaris and HP-UX. Should that go into porting (as it affects two platforms), or just Solaris, as that is the main porting effort? > Stupid example: say I want to rename the matrix method "echelonize" to > "echelonise". I write a patch implementing this today, and Minh is so > happy about seeing this that he immediately gives it a positive > review. So I make a new ticket titled "2010-11-02: get rid of > M.echelonize", and I mention the original ticket in the description. Seems reasonable, but trac would need to have added a type 'deprecation'. Someone would have to look at that periodically. PS. It would be really good to get rid of the warning about the 'md5' module one gets when typing notebook(). This must be one of the very first things a new user does, and he gets a warning. Having that sort of thing happen on rarely used bits of Sage is acceptable, but I think that particular bit should be fixed if it can. ********************************************************************** sage: notebook() The notebook files are stored in: /export/home/drkirkby/.sage//sage_notebook ************************************************** * * * Open your web browser to http://localhost:8000 * * * ************************************************** /export/home/drkirkby/sage/gcc32-sage-4.1.2.rc0/local/lib/python2.6/site-packages/twisted/persisted/sob.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys Dave --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
