- Tim Joseph Dumol <tim (at) timdumol (dot) com>
On Sun, Nov 1, 2009 at 10:49 PM, Dr. David Kirkby <david.kir...@onetel.net>wrote: > > 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? > Perhaps a tag would be more appropriate to indicate deprecation, then. > > > 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 -~----------~----~----~----~------~----~------~--~---
