On Jan 26, 2009, at 11:48 AM, William Stein wrote: > On Mon, Jan 26, 2009 at 11:35 AM, Robert Bradshaw > <rober...@math.washington.edu> wrote: >> >> On Jan 25, 2009, at 9:00 AM, William Stein wrote: >> >>> On Sun, Jan 25, 2009 at 8:44 AM, mabshoff <mabsh...@googlemail.com> >>> wrote: >>>> >>>> >>>> >>>> On Jan 25, 8:20 am, Martin Albrecht <m...@informatik.uni-bremen.de> >>>> wrote: >>>>>> 4.0 was discussed >>>>> >>>>> I think we should agree way in advance when 4.0 is going to be >>>> >>>> +1 >>>> >>>>> and then allow >>>>> ourselves to break backwards compatibility: i.e. go through and >>>>> remove a >>>>> bunch of cruft (at least the stuff that has a DeprecationWarning). >>>> I don't think it is a good idea at all. Deprecation warnings are >>>> the >>>> way to go and I think even six months is too little time to give >>>> the >>> >>> I also think the above suggestion about 4.0 by Martin is not so >>> good. >>> We already hashed out a deprecation policy, which is a gradual >>> timed (usually >>> 6-month) phasing out of functionality with DeprecationsWarning's. >>> I think it >>> works well, and that we should stick to it. >> >> I think DeprecationsWarnings are the way to go too, but Martin has a >> point that when we do actually drop support it shouldn't be on some >> tiny point release. > > So the idea is that in Sage 4.0 we will drop all code that yields > DeprecationWarnings and has already been in Sage for at least 6 > months? I.e., we only purge deprecated code older than 6 months > during major releases, but not during point releases? > > I think a major release like 4.0 should (1) have reached some major > longterm milestones (e.g., Solaris port, 70% doctest coverage, etc.), > and also (2) be unusually rock solid. Deleting a bunch of code is > likely to cause subtle problems we don't think about, which conflicts > with (2). > I know that (2) is different than what most software projects do, > where their major new version releases are an unstable mess.
I'm with you on both points. When I say "tiny point release" I mean something like 3.4.2 -> 3.2.3. It would make more sense to have a 3.x -> 3.x+1 release whose primary feature is removing deprecated cruft. I could see this being a very short release cycle (basically deleting huge chunks of code that have had a deprecation warnings for a while) and not done very often. That way it wouldn't be buried in the release notes of an ordinary-looking release, and also if something breaks on a give version it would be easier to pinpoint using deprecated functionality as the cause. I don't think we should necessarily tie it to major releases though. - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
