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 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. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
