On Sun, 25 Jan 2009 09:19:54 -0800 Martin Albrecht <m...@informatik.uni-bremen.de> wrote:
> > How about we agree *months* ahead on when a new major release is > supposed to hit the shelves.Then say two month before that release we > make a freeze on stuff that can be removed in the next release, so > that I know if I want to get rid of a certain function, I have to do > it within a well known time frame. I still think that we should seize > the opportunity to break backward compatibility in a new major > release like x.0. I like this idea. Sage is too young to stabilize its interfaces. Keeping the cruft in there will just make it harder to maintain the library and discourage people from taking the time to fix things properly. We shouldn't forget that the development process of Sage is much different than other CASs, some of which strive to keep backward compatibility even with ancient versions. Many people use Sage because it improves rapidly, and they can easily influence the development or contribute to it. They enjoy the advantage of having access to the new features immediately, but they also have to keep up with a moving target. If you write code using a well developed area of Sage, I doubt that your code will break very often. Unfortunately, at this stage, there aren't many "well developed" areas. > I never suggested to get rid of deprecation warnings. Right now, Sage > 3.3.2.1 might break backward compatibility because it happens to be > six months after some developer decided to deprecate a certain > function. This situation *way* less predictable than following the > standard strategy for dealing with version numbers. The deprecation warnings are not the silver bullet either. We go about changing the interface to specific functions freely. When things break in this case, the user has to look in the documentation of that function and figure out what changed. All that is provided by a deprecation warning is a pointer to the new documentation. Instead of trying to keep old code from working, we should document the processes with which users can test their code when they upgrade Sage. The doctest framework already provides the basis for this, it is just not clear to many people how to use it for code developed outside the Sage library. Burcin --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
